[Bug testsuite/57686] FAIL: gcc.dg/torture/pr57584.c with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57686 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Version|unknown |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- .
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 --- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Janne Blomqvist from comment #13) I believe a lot of progress has been made indeed. However, the fundamental(?) issue of module sizes growing exponentially with deep module hierarchies still remains. The solution to that is to not include transitive dependencies, which in turn would require a module cache for good performance. Whether that is worth doing, and who is willing and able to do it, is unclear. note that there could also be disadvantages for that solution. For example, dependencies for a given .F would be more difficult to find (i.e. not just the USE statements). I'm not sure what implications that would have e.g. for 'smart' recompilation (i.e. based on time stamps of .mod). The module cache would also not work very well for the (common, I guess) case of having a single module per file, and all USE statements on top. It might thus be that the current state is the sweet spot.
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Was marked as ASSIGNED, but actually Not yet assigned to anyone. Set to NEW.
[Bug fortran/47267] array constructor causing long compile times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47267 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Was marked as ASSIGNED, but actually Not yet assigned to anyone. Set to NEW.
[Bug fortran/25708] [F95] Module loading is not good at all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #23 from Dominique d'Humieres dominiq at lps dot ens.fr --- Was marked as ASSIGNED, but actually Not yet assigned to anyone. Set to NEW.
Re: confirm unsubscribe from gcc-bugs@gcc.gnu.org
On 2013-06-24 09:11, gcc-bugs-h...@gcc.gnu.org wrote: Hi! This is the ezmlm program. I'm managing the gcc-bugs@gcc.gnu.org mailing list. To confirm that you would like joop.boo...@boonen.org removed from the gcc-bugs mailing list, please send an empty reply to this address: gcc-bugs-uc.1372057878.ilaghhpkihfgnfkidodi-joop.boonen=boonen@gcc.gnu.org Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. I haven't checked whether your address is currently on the mailing list. To see what address you used to subscribe, look at the messages you are receiving from the mailing list. Each message has your address hidden inside its return path; for example, m...@xdd.ff.com receives messages with return path: gcc-bugs-return-number-mary=xdd.ff@gcc.gnu.org. Some mail programs are broken and cannot handle long addresses. If you cannot reply to this request, instead send a message to gcc-bugs-requ...@gcc.gnu.org and put the entire address listed above into the Subject: line. --- Administrative commands for the gcc-bugs list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: To subscribe to the list, send a message to: gcc-bugs-subscr...@gcc.gnu.org To remove your address from the list, send a message to: gcc-bugs-unsubscr...@gcc.gnu.org Send mail to the following for info and FAQ for this list: gcc-bugs-i...@gcc.gnu.org gcc-bugs-...@gcc.gnu.org Similar addresses exist for the digest list: gcc-bugs-digest-subscr...@gcc.gnu.org gcc-bugs-digest-unsubscr...@gcc.gnu.org To get messages 123 through 145 (a maximum of 100 per request), mail: gcc-bugs-get.123_...@gcc.gnu.org To get an index with subject and author for messages 123-456 , mail: gcc-bugs-index.123_...@gcc.gnu.org They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send an empty message to: gcc-bugs-thread.12...@gcc.gnu.org The messages do not really need to be empty, but I will ignore their content. Only the ADDRESS you send to is important. You can start a subscription for an alternate address, for example john@host.domain, just add a hyphen and your address (with '=' instead of '@') after the command word: gcc-bugs-subscribe-john=host.dom...@gcc.gnu.org To stop subscription for this address, mail: gcc-bugs-unsubscribe-john=host.dom...@gcc.gnu.org In both cases, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete your subscription. If despite following these instructions, you do not get the desired results, please contact my owner at gcc-bugs-ow...@gcc.gnu.org. Please be patient, my owner is a lot slower than I am ;-) --- Enclosed is a copy of the request I received. Return-Path: anonym...@sourceware.org Received: (qmail 28832 invoked by uid 48); 24 Jun 2013 07:11:18 - Message-ID: 20130624071118.28829.qm...@sourceware.org From: anonym...@sourceware.org Date: Mon, 24 Jun 2013 07:11:18 + To: gcc-bugs-unsubscribe-joop.boonen=boonen@sourceware.org User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
[Bug c++/57693] New: The program logically failed in case of used int b += b++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57693
Bug ID: 57693
Summary: The program logically failed in case of used int b +=
b++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vlad94009277 at gmail dot com
Steps to reproduce:
1. Write the following source cod and compile it:
#include iostream
using namespace std;
int main(){
int d = 7;
int c = 7;
int b = c;
b += b++;
d += d++;
cout c = c endl;
cout d = d endl;
return 0;
}
2. Run the appropriate generated executable file.
Actual result:
It's printed:
c = 8
d = 15
Expected result:
It should be printed:
c = 15
d = 15
Please note that there are different assemble codes for used operators:
1) d += d++
movl -4(%rbp), %eax // Copies value of d to register %eax
addl %eax, %eax // Adds %eax to %eax, remembers the value in %eax
movl %eax, -4(%rbp) // Moves %eax to d (d = 14)
addl $1, -4(%rbp) // Increments the value of d (d = 15)
2) b += b++
movl -12(%rbp), %eax // Moves the value of b to %eax
movl -12(%rbp), %edx // Moves the value of b to %edx
leal (%rax,%rdx), %edx // Adds %rax to %rdx and stores result in %edx (%rax and
%rdx are equal to 7, so after this operation %edx is 14)
movl %edx, -12(%rbp) // Moves %edx to d (d = 14)
addl $1, %eax // Increments the value of %eax (%eax = 8).
movl %eax, -12(%rbp) // Moves %eax to d (d = 8)
[Bug c++/57693] The program logically failed in case of used int b += b++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57693 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Both: b += b++; And d += d++; are undefined what value b and d is going to be as there are no sequence point intbetween the two assignments. They could be: temp = b; b++; b += temp; or b++; b+=b;
[Bug c++/57694] New: [c++11] constexpr constructor do not work with const address of own member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57694
Bug ID: 57694
Summary: [c++11] constexpr constructor do not work with const
address of own member
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lts-rudolph at gmx dot de
The following code results in
error: field initializer is not constant
class A
{
private:
int a;
const int* const aptr;
public:
constexpr A( int _a):
a(_a)
, aptr( a) // why aptr could not be initialized?
{}
};
class Data { } d1;
class B
{
private:
Data* dptr1;
public:
constexpr B(Data* _p): dptr1( _p) {}
};
class Use
{
static constexpr A a{2}; // fail! error: field initializer is not
constant
static constexpr B b{d1}; // works
};
[Bug c++/57694] [c++11] constexpr constructor do not work with const address of own member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57694 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1
[Bug c++/57693] The program logically failed in case of used int b += b++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57693 --- Comment #2 from Vladimir vlad94009277 at gmail dot com --- (In reply to Andrew Pinski from comment #1) Both: b += b++; And d += d++; are undefined what value b and d is going to be as there are no sequence point intbetween the two assignments. They could be: temp = b; b++; b += temp; or b++; b+=b; I tried this issue on version 4.8.1 and it works successfully. It seems the bug was already fixed.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Allan McRae from comment #13) The file /usr/include/stdc-predef.h is from glibc (v2.17 on Arch) and is specifically mentioned as being preincluded in http://gcc.gnu.org/gcc-4.8/porting_to.html. In fact, using -ffreestanding solves the issue. So when you use -ffreestanding, is stdc-predef.h still included? You could put a break in push_command_line_include and check if -include foo.h still includes stdc-predef.h and whether it shows also the problem. If the file is included but there is no bug, then my guess is that the code executed before or after the pre-include stdc-predef.h is missing something for the -imacros case. If it shows the bug, then the code for pre-including stuff must be wrong somehow, perhaps cpp_push_default_include is doing something wrong when compared to cpp_push_include.
[Bug c++/57695] New: [c++11] generalized attributes with avr __progmem__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57695
Bug ID: 57695
Summary: [c++11] generalized attributes with avr __progmem__
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lts-rudolph at gmx dot de
The two statements:
extern const X x __attribute__ ((__progmem__)) = { 1 }; // works as expected
extern const X x [[__progmem__]] = { 1 };// warning broken
code
See the following description to get working example.
The following code compiles as expected with avr-g++ 4.8.1: (code must split in
different translation units to see any result, because the optimizer will
remove all effects while inlining the instructions)
x.h:
struct X
{
uint8_t a;
};
x.cpp:
extern const X x __attribute__ ((__progmem__)) = { 1 };
main.cpp:
#include x.h
extern const X x __attribute__ (( __progmem__ ));
int main()
{
PORTB = pgm_read_byte( (x.a));
return 0;
}
results in (objdump -d):
001a x:
1a: 01 00 ..
...
2e: ea e1 ldi r30, 0x1A ; 26
30: f0 e0 ldi r31, 0x00 ; 0
32: c8 95 lpm
the result is fine.
Using generalized attributes do NOT work:
extern const X x [[__progmem__]] = { 1 };
this results in a warning x.cpp:8:32: warning: 'progmem' attribute directive
ignored [-Wattributes] and the code is broken because the var x is stored to
ram instead of flash.
[Bug c++/57693] The program logically failed in case of used int b += b++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57693 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- You are not listening, the only bug here is in your testcase, not in the compiler.
[Bug c++/57695] [c++11] generalized attributes with avr __progmem__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57695 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Probably because you should be using [[gnu::progmem]] or [[gnu::__progmem__]].
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jun 24 08:43:55 2013 New Revision: 200361 URL: http://gcc.gnu.org/viewcvs?rev=200361root=gccview=rev Log: 2013-06-24 Steven G. Kargl s...@troutmask.apl.washington.edu Francois-Xavier Coudert fxcoud...@gcc.gnu.org Dominique d'Humieres domi...@lps.ens.fr PR fortran/52413 * simplify.c (gfc_simplify_fraction): Fix the sign of negative values. 2013-06-24 Francois-Xavier Coudert fxcoud...@gcc.gnu.org Dominique d'Humieres domi...@lps.ens.fr PR fortran/52413 * gfortran.dg/fraction.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/fraction.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED on the trunk (GCC 4.9). Thanks for the report!
[Bug c++/57695] [c++11] generalized attributes with avr __progmem__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57695 Klaus Rudolph lts-rudolph at gmx dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Klaus Rudolph lts-rudolph at gmx dot de --- @Jakub: [[gnu::__progmem__]] works! [[gnu::progmem]] fails. Thanks a lot!
[Bug c++/57693] The program logically failed in case of used int b += b++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57693 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Both: b += b++; And d += d++; are undefined what value b and d is going to be as there are no sequence point intbetween the two assignments. They could be: temp = b; b++; b += temp; or b++; b+=b; Please, could we make more use of the FAQ? http://gcc.gnu.org/wiki/FAQ#undefinedbut If you think the answer does not provide enough information, just extend the answer there. (it could mention some example, and -Wsequence-points). Otherwise, we have the same back and forth over and over again to the frustration of users and the time waste of developers: what is UB? but my program worked before! but my program works without optimizations! but I know how it should work! can't gcc be consistent? but UB should not affect my problem! I think this should not be UB!
[Bug fortran/57696] New: Defined assignment for components not used when those are ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57696 Bug ID: 57696 Summary: Defined assignment for components not used when those are ALLOCATABLE Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: pault at gcc dot gnu.org The following prints 42 42 with gfortran and 42 20 with crayftn. Thus, gfortran does not use defined assignment - but it should. Note: If right%foo is not allocated, the code segfaults with crayftn. module m0 implicit none type component integer :: i = 42 contains procedure :: assign0 generic :: assignment(=) = assign0 end type type parent type(component), allocatable :: foo end type contains elemental subroutine assign0(lhs,rhs) class(component), intent(INout) :: lhs class(component), intent(in) :: rhs lhs%i = 20 end subroutine end module program main use m0 implicit none type(parent) :: left, right allocate(right%foo) print *, right%foo left = right print *, left%foo end
[Bug rtl-optimization/57518] [4.8/4.9 Regression] Redundant insn generated in LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.0 |4.8.2 Summary|[4.9 Regression] Redundant |[4.8/4.9 Regression] |insn generated in LRA |Redundant insn generated in ||LRA Known to fail||4.8.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Not sure if we want to backport such change though.
[Bug tree-optimization/57488] [4.9 regression] loop terminates early at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57488 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jun 24 10:22:22 2013 New Revision: 200363 URL: http://gcc.gnu.org/viewcvs?rev=200363root=gccview=rev Log: 2013-06-24 Richard Biener rguent...@suse.de PR tree-optimization/57488 * tree-ssa-pre.c (insert): Clear NEW sets before each iteration. * gcc.dg/torture/pr57488.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57488.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug fortran/57696] Defined assignment for components not used when those are ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57696 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- From Fortran 2008, 7.2.1.3 Interpretation of intrinsic assignments, paragraph 13 (excerpt): For a noncoarray allocatable component the following sequence of operations is applied. (1) If the component of the variable is allocated, it is deallocated. (2) If the component of the value of expr is allocated, the corresponding component of the variable is allocated with the same dynamic type and type parameters as the component of the value of expr. If it is an array, it is allocated with the same bounds. The value of the component of the value of expr is then assigned to the corresponding component of the variable using defined assignment if the declared type of the component has a type-bound defined assignment consistent with the component, and intrinsic assignment for the dynamic type of that component otherwise.
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #26 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #25) Created attachment 30346 [details] conti This patch creates references where the referring node is the old one, not the newly created clone. I think that create_specialized_node should traverse aggvals and create the references. Hopefully I can prepare a patch doing that in the course of this afternoon (but of course feel free to make one yourself if you are faster).
[Bug go/57689] [4.8 Regression] ICE (segfault) building libgo on ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57689 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.2
[Bug testsuite/57686] FAIL: gcc.dg/torture/pr57584.c with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57686 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Oops.
[Bug tree-optimization/57685] [4.8/4.9 Regression] GCC stuck in an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-24 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.8.2 Summary|GCC stuck in an infinite|[4.8/4.9 Regression] GCC |loop|stuck in an infinite loop Ever confirmed|0 |1 Known to fail||4.8.1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, mine.
[Bug rtl-optimization/57676] [4.8/4.9 Regression] ICE: Maximum number of LRA constraint passes is achieved (30)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57676 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Keywords||ra Last reconfirmed||2013-06-24 CC||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE: Maximum number of LRA |[4.8/4.9 Regression] ICE: |constraint passes is|Maximum number of LRA |achieved (30) |constraint passes is ||achieved (30) Target Milestone|--- |4.8.2 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug middle-end/323] optimized code gives strange floating point results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||oliverst at online dot de --- Comment #191 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 57669 has been marked as a duplicate of this bug. ***
[Bug target/57669] Incorrect floating point values with 32-bit compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57669 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Dup. *** This bug has been marked as a duplicate of bug 323 ***
[Bug fortran/57696] Defined assignment for components not used when those are ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57696 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug other/57668] Regression in vectorizing memcpy pattern.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57668 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. memcpy_byte.c:2: note: Completely unroll loop 14 times the new unrolling code unrolls the epilogue loop completely: Estimating sizes for loop 3 BB: 8, after_exit: 0 size: 0 i.0_40 = (sizetype) i_38; size: 1 _41 = s_7(D) + i.0_40; size: 1 _42 = d_9(D) + i.0_40; size: 1 _43 = *_42; size: 1 *_41 = _43; size: 1 i_45 = i_38 + 1; size: 2 if (i_45 _16) Exit condition will be eliminated in last copy. BB: 9, after_exit: 1 size: 7-0, last_iteration: 7-2 Loop size: 7 Estimated size after unrolling: 68 And loop distribution fails to detect the memcpy clone, too.
[Bug debug/57664] [4.8/4.9 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6750 with -fdebug-types-section and lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57664 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.2
[Bug rtl-optimization/57662] [4.9 Regression] ICE: SIGSEGV in code_motion_process_successors with -fschedule-insns2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57662 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/57661] [4.9 Regression] ICE: SIGSEGV in verify_ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57661 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, we are missing the SSA_NAME_DEF_STMT for _18.
[Bug testsuite/57686] FAIL: gcc.dg/torture/pr57584.c with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57686 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jun 24 11:14:31 2013 New Revision: 200364 URL: http://gcc.gnu.org/viewcvs?rev=200364root=gccview=rev Log: 2013-06-24 Richard Biener rguent...@suse.de PR testsuite/57686 * gcc.dg/torture/pr57584.c: Remove target specific bits. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr57584.c
[Bug fortran/57697] New: Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697
Bug ID: 57697
Summary: Segfault with defined assignment for components during
intrinsic assignment
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Found with ForTrilinos's ForTrilinos_ADT_3D_Burgers_6th_Pade example.
For the code:
function new_scalar_field(initial,comm) result(this)
...
if (.not. allocated(map)) then
map = Epetra_Map(NumGlobalElements,NumMyElements,IndexBase,comm)
gfortran generates the code:
static struct epetra_map * _F.DA104 = 0B;
static struct universal _F.DA105;
...
if (map == 0B)
{
{
static integer(kind=4) C.5077 = 1;
static integer(kind=4) C.5076 = 4096;
if (_F.DA104 != 0B) goto L.249;
_F.DA104 = (struct epetra_map *) __builtin_malloc (56);
L.249:;
*_F.DA104 = create_linear (C.5076, nummyelements, C.5077,
(struct __class_fepetra_comm_Epetra_comm *) comm);
}
_F.DA105 = map-epetra_blockmap.universal;
if (map != 0B) goto L.251;
map = (struct epetra_map *) __builtin_malloc (56);
L.251:;
*map = *_F.DA104;
Note that the assignment to _F.DA105 dereferences map, which is known to be
NULL!
[Bug tree-optimization/57698] New: rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 Bug ID: 57698 Summary: rev.200179 causes many errors (inlining failures) when building Firefox Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: markus at trippelsdorf dot de I cannot build Firefox anymore with trunk because of inline errors, e.g.: /home/markus/mozilla-central/js/src/jsapi.h: In function ‘js::regexp_exec(JSContext*, unsigned int, JS::Value*)’: /home/markus/mozilla-central/js/src/builtin/RegExp.cpp:307:1: error: inlining failed in call to always_inline ‘IsRegExp(JS::Value const)’: indirect function call with a yet undetermined callee IsRegExp(const Value v) ^ In file included from /home/markus/mozilla-central/js/src/jsprvtd.h:24:0, from /home/markus/mozilla-central/js/src/builtin/RegExp.h:10, from /home/markus/mozilla-central/js/src/builtin/RegExp.cpp:7: /home/markus/mozilla-central/js/src/jsapi.h:706:5: error: called from here if (Test(thisv)) IMO that is to aggressive (and will affect many projects). Wouldn't a simple warning be enough?
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Status|RESOLVED|NEW Version|4.7.0 |4.8.1 Resolution|FIXED |--- --- Comment #16 from dominik.stras...@onespin-solutions.com --- The situation is much improved in 4.8.1, but still not usable for me in bigger configurations: time ./a.out 1 real0m0.907s user0m0.904s sys0m0.003s time ./a.out 2 real0m3.713s user0m3.708s sys 0m0.001s time ./a.out 4 real 0m13.820s user0m13.812s sys 0m0.001s time ./a.out 8 real0m56.759s user0m56.729s sys0m0.001s Still O(n^2). (I modified the test program to use argv[1] as loop counter. W/o _GLIBCXX_DEBUG: time ./a.out 1 real0m0.008s user0m0.006s sys0m0.002s ./a.out 2 real0m0.013s user0m0.008s sys0m0.004s ./a.out 4 real0m0.013s user0m0.013s sys0m0.000s ./a.out 8 real0m0.026s user0m0.024s sys0m0.002s Which shows O(n) behavior.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #17 from dominik.stras...@onespin-solutions.com --- Created attachment 30350 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30350action=edit New testcase
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This doesn't make any sense to me.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Attachment #27332|0 |1 is obsolete|| Attachment #30350|0 |1 is obsolete|| --- Comment #18 from dominik.stras...@onespin-solutions.com --- Created attachment 30351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30351action=edit Really new testcase
[Bug fortran/57639] [OOP] ICE with polymorphism (and illegal code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57639 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- (In reply to janus from comment #4) The following patch fixes both variants: ... and regtests cleanly. Confirmed.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com --- I'm not going to work on this anyway, but really I'm not at all sure that debug-mode is by design made for bigger configurations, thus makes sense to give high priority to this kind of issue. Unless of course users actively contribute improvements.
[Bug tree-optimization/57656] [4.7/4.8/4.9 Regression] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57656 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 30352 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30352action=edit patch Fails at -O0 -fstrict-overflow as we fold int t = 1 - (a - b) / c; into int t = (b - a) / c + 1; The change in r117969 exposed a bug in negate_expr_p, namely that we cannot negate (a - b) / c as (b - a) / c because that associates the negate with the division which exposes possible undefined overflow in -(a - b) that is not there in the original expression for c != +-1. This is a bit a problem with the negate_expr_p specification - the API doesn't specify whether we are removing an existing negate or whether we are adding one. This case removes one from the division and adds it to the subtraction. -(a - b) - (b - a) is ok, but (a - b) - -(b - a) is not - the API doesn't really distinguish these two cases but in the MINUS_EXPR case clearly implements -(a - b) - (b - a). Testing the attached.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- I think this is due to a horrible hack in the front end which adds implicit extern C blocks around system headers, and a side-effect is that function prototypes of the form 'T f()' are treated as 'T f(...)' as in C, not 'T f(void)' as C++ requires. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982#c40 for another case where this bit us. This is a terrible terrible hack IMHO, and should be disabled in libstdc++ headers, because when we write void(*)() we damn well mean it, we don't mean something different. Having to use void(*)(void) is an abomination.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com --- And we already analyzed the issue and figured out that further improvements aren't part of it (See Comment 6 and 9).
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Yes it is, a huge abomination, I had no idea we had something like that. Then, I don't know, I don't think it's going away any time soon, probably we should bite the bullet and add those void with a big comment for the time being?
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- ... by the way, I'm *very* surprised that nobody noticed this over the years: the freestanding atexit is declared like this in cstdlib in 4.0.0!?!
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- I'm adding Jakub in CC.
[Bug c++/57699] New: Disable empty parameter list misinterpretation in libstdc++ headers when !defined(NO_IMPLICIT_EXTERN_C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
Bug ID: 57699
Summary: Disable empty parameter list misinterpretation in
libstdc++ headers when !defined(NO_IMPLICIT_EXTERN_C)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
In cp/parser.c the function cp_parser_parameter_declaration_clause has:
else if (token-type == CPP_CLOSE_PAREN)
/* There are no parameters. */
{
#ifndef NO_IMPLICIT_EXTERN_C
if (in_system_header current_class_type == NULL
current_lang_name == lang_name_c)
return NULL_TREE;
else
#endif
return void_list_node;
}
This means that on implicit extern C systems (ones not known to have C++
compatible libc headers) we interpret void(*)() as void(*)(...)
This might be necessary to properly handle libc headers on those systems, but
should not be enabled for libstdc++ headers (or more generally, any headers
actually written in C++) because when we write void(*)() in C++ we damn well
mean what we wrote, we shouldn't have to say void(*)(void)
This has caused problems more than once in libstdc++, where correct C++ code in
an explicit extern C block is misinterpreted by the front end, because
libstdc++ headers are system headers (due to the #pragma we use) and we
sometimes have to declare functions in extern C blocks. The problems are not
found immediately because they only happen on less-tested targets such as AIX
and eCos:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982#c40
It would be nice to have some way to mark libstdc++ headers to prevent the code
above returning NULL_TREE.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #21 from dominik.stras...@onespin-solutions.com --- How can I help ? My goal is to run our entire regression test suite with STL debugging switched on as this is great for quality assurance. Having fought several problems, this now seems to be my final obstacle. After one year I now have a fix in a GCC release but unfortunately still no cigar. If you point me to sth. where I can look at I will happily try to contribute.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- I've opened PR 57699 -- it would be nice not to have to write (void) in our headers.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com --- Get in touch with Francois and work on further improvements with him.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #4) ... by the way, I'm *very* surprised that nobody noticed this over the years: the freestanding atexit is declared like this in cstdlib in 4.0.0!?! It only matters on some less-well-tested targets, because NO_IMPLICIT_EXTERN_C is defined for sane targets. It might also not matter if the system headers declare: int atexit(void (*)(void)); as GNU Libc does, because then the function is declared portably for both C and C++. Presumably the eCos headers either don't declare atexit or declare it without an abominable (void) parameter list.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Of course. Since, AFAIK, we already had the sensible () with no void in like 2005, communities outside GCC must have workarounds in place, can wait a bit more. Let's mark the C++ front-end issue as blocking this one.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Jonathan Wakely from comment #7) (In reply to Paolo Carlini from comment #4) ... by the way, I'm *very* surprised that nobody noticed this over the years: the freestanding atexit is declared like this in cstdlib in 4.0.0!?! It only matters on some less-well-tested targets, because NO_IMPLICIT_EXTERN_C is defined for sane targets. It might also not matter if the system headers declare: int atexit(void (*)(void)); as GNU Libc does, because then the function is declared portably for both C and C++. Presumably the eCos headers either don't declare atexit or declare it without an abominable (void) parameter list. the eCos stdlib.h declares it the right way: stdlib.h:/* Type of function used by atexit() */ stdlib.h:typedef void (*__atexit_fn_t)( void ); stdlib.h:atexit( __atexit_fn_t /* func_to_register */ ); but because the cstdlib has this guard block it declares every thing by itself: #if !_GLIBCXX_HOSTED // The C standard does not require a freestanding implementation to // provide stdlib.h. However, the C++ standard does still require // cstdlib -- but only the functionality mentioned in // [lib.support.start.term].
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Uhm. I can't say to understand all the details of this wrt the various targets and the front-end, but given that C++11 *spells out* in 18.5 those damn void, I suppose we could do that in our implementation and be done with it. Jon, what do you think?
[Bug tree-optimization/57539] [4.9 Regression] ice in ipa_edge_duplication_hook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57539 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Mon Jun 24 12:40:17 2013 New Revision: 200368 URL: http://gcc.gnu.org/viewcvs?rev=200368root=gccview=rev Log: 2013-06-24 Martin Jambor mjam...@suse.cz PR tree-optimization/57539 * cgraphclones.c (cgraph_clone_node): Add parameter new_inlined_to, set global.inlined_to of the new node to it. All callers changed. * ipa-inline-transform.c (clone_inlined_nodes): New variable inlining_into, pass it to cgraph_clone_node. * ipa-prop.c (ipa_propagate_indirect_call_infos): Do not call ipa_free_edge_args_substructures. (ipa_edge_duplication_hook): Only add edges from inlined nodes to rdesc linked list. Do not assert rdesc edges have inlined caller. Assert we have found an rdesc in the rdesc list. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/cgraphclones.c trunk/gcc/ipa-inline-transform.c trunk/gcc/ipa-inline.c trunk/gcc/ipa-prop.c trunk/gcc/lto-cgraph.c
[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57358 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Mon Jun 24 12:51:43 2013 New Revision: 200369 URL: http://gcc.gnu.org/viewcvs?rev=200369root=gccview=rev Log: 2013-06-24 Martin Jambor mjam...@suse.cz PR tree-optimization/57358 * ipa-prop.c (ipa_func_spec_opts_forbid_analysis_p): New function. (ipa_compute_jump_functions_for_edge): Bail out if it returns true. (ipa_analyze_params_uses): Generate pessimistic info when true. testsuite * gcc.dg/ipa/pr57358.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr57358.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, that will fix it right now. In the longer term it would be nice to get a FE change.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com --- Sure, if we close this the C++ front-end issue remains open. I will commit the tweak to c_std and c_global, mainline only.
[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57358 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Mon Jun 24 12:57:52 2013 New Revision: 200370 URL: http://gcc.gnu.org/viewcvs?rev=200370root=gccview=rev Log: 2013-06-24 Martin Jambor mjam...@suse.cz PR tree-optimization/57358 * ipa-prop.c (parm_ref_data_preserved_p): Always return true when not optimizing. testsuite/ * gcc.dg/ipa/pr57358.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/ipa/pr57358.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/ipa-prop.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Created attachment 30353 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30353action=edit Test case
[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 30353 [details] Test case Should not this go to PR57696?
[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) Should not this go to PR57696? No. The examples are similar, but they expose rather different bugs. PR57696 has already a test case and the problem there is that no defined assignment is done for an allocatable component. - Wrong code as the defined assignment is not invoked. This PR (and attachment 30353) is about an unallocated allocatable LHS, where for a component defined assignment is used. - Wrong code as it segfaults at run time.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug tree-optimization/57521] [4.7/4.8/4.9 Regression] wrong code for expressions in loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- It's if-conversion (we do not vectorize anything here). The predicates are inserted correctly but the wrong ones are being used for the predication. That is because the predecessor edge we chose in find_phi_replacement_condition is not fallthru and thus the predicate we chose is bogus. It seems to assume that critical edges are split. I have a patch.
[Bug other/57700] New: doc: improperly named node about Diagnostic Messages Formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57700 Bug ID: 57700 Summary: doc: improperly named node about Diagnostic Messages Formatting Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: akim.demaille at gmail dot com The node about Options to Control Diagnostic Messages Formatting seems to be named Language Independent Options (or something is wrong with the structure of Texinfo doc in there). See http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html and look at the title of the page. Of course the TOC is wrong etc. (And FWIW, there appears to be no appropriate Component in the bug tracker for documentation issues).
[Bug other/57700] doc: improperly named node about Diagnostic Messages Formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57700 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Akim Demaille from comment #0) See http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html and look at the title of the page. Of course the TOC is wrong etc. The URL should be http://gcc.gnu.org/onlinedocs/gcc/Language-Independent-Options.html (And FWIW, there appears to be no appropriate Component in the bug tracker for documentation issues). Because documentation bugs should be assigned to the relevant component so the relevant maintainers can fix it, e.g. libstdc++ docs bugs get assigned to libstdc++. There's a documentation keyword instead.
[Bug tree-optimization/57701] New: Incorrect optimisation of inlined function with inline assembly when cross-compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701 Bug ID: 57701 Summary: Incorrect optimisation of inlined function with inline assembly when cross-compiling Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sqweek at gmail dot com Created attachment 30354 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30354action=edit Standalone source file for reproducing gcc version 4.8.1 (GCC) My system is x86_64-unknown-linux-gnu, but I'm cross-compiling to x86 (-m32) Configured with: /build/gcc-multilib/src/gcc-4.8.1/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --enable-multilib --disable-libssp --disable-werror --enable-checking=release I'm running the gcc-multilib binary from archlinux, which slightly modifies the stock gcc build - it doesn't run fixinc.sh and adds -O2 to some configure tests. I suspect they are not important, but in the interest of full disclosure the details available in the prepare() function at https://projects.archlinux.org/svntogit/community.git/tree/repos/multilib-x86_64/PKGBUILD?h=packages/gcc-multilib The problem: I've attached a program (which I've tried to make smaller but failed to reproduce the problem) that runs fine when compiled with no flags, but fails when compiled with -O. -O2 also fails, but -O3 works again *shrug*. Build commands: gcc -m32 fpe.c -o fpe #produces a working binary gcc -m32 -O fpe.c -o fpe-O #produces the failing binary Anyway, the code uses inline assembly to setup the floating point unit, then calculates 0./0. The expected result is a NaN, but when compiled with -O the FPU gets setup differently and we get a SIGFPE instead. I'm pretty new at assembler, but I *think* I've ruled that out as the cause, I've been stepping through the instructions in gdb and the results from the inline assembly sections appear to be the same. The value returned from getFPcontrol() seems to be where the differences begun.
[Bug tree-optimization/57701] Incorrect optimisation of inlined function with inline assembly when cross-compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You do not properly specify the side-effects of the asms so the compiler assumes it can freely re-order things as it likes.
[Bug libitm/57643] libitm.c/reentrant.c hangs on POWER8 with HTM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57643 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Peter Bergner bergner at gcc dot gnu.org --- This was confirmed fixed (on Power and S390) with Torvald's two patches: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01132.html (revision 200250) http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01188.html (revision 200251)
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #27 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 30355 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30355action=edit Proposed patch I'd suggest this (yet untested) patch.
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- I saw this too. There is always_inline (force_inline in the source) function taking always_inline as a callback and we don't work hard enough to inline all of them. I am not sure if GCC is missing some indirect call inlining or it is bug in firefox. Concerning error/warning We generally output error when always_inline is not inlined for some reason, so it seems bit odd to error sometimes and warn at other times. We also may just have disregard_inline_limits attribute for uses like this. Honza
[Bug tree-optimization/57702] New: Reassoc missed optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57702
Bug ID: 57702
Summary: Reassoc missed optimizations
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
On:
int f1 (int x, int y) { x += y; return x + 3 * y; }
unsigned int f2 (unsigned int x, unsigned int y) { x += y; return x + 3 * y; }
int f3 (int x, int y) { x += 7 * y; return x + 12 * y; }
unsigned int f4 (unsigned int x, unsigned int y) { x += 7 * y; return x + 12 *
y; }
reassoc optimizes only the f4 function into x += 19 * y; at the tree level, and
at the RTL level combiner happens to optimize it except for f3, which has more
insns than f4. I don't see why not optimizing this even for signed types would
be problematic, as long as the multiplication is performed in the same signed
type and all terms have the same sign (with different sizes the optimization
could remove undefined overflow, but I don't see how it could introduce it).
When things are vectorized the RTL optimizations will hardly help though.
[Bug fortran/46982] SIZE(TRANSFER()) as specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46982 --- Comment #5 from Harald Anlauf anlauf at gmx dot de --- (In reply to Dominique d'Humieres from comment #4) ... So I think that the code in comment #0 is not legal. Then, should not this PR closed as INVALID? Yes, close as INVALID. -- For the record: NAG Fortran Compiler Release 5.3.1(928) says SOMETHING is not permitted in an initialisation expression and xlf 14.01..0003 complains: Variable something_array was declared as array of type ADJUSTABLE. This type of array is not permitted in a main program. Only pgi 13.4-0 accepts it, but I believe that it shouldn't.
[Bug fortran/46982] SIZE(TRANSFER()) as specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46982 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Yes, close as INVALID. Hence closed.
[Bug fortran/34928] Extension: volatile common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Bud, What was the purpose of this construct? What is the valid way to replace it?
[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997 --- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de --- 1. you should never touch memory that lies outside the struct. 2. if you have to generate multiple accesses you should generate code as if volatile was not used at all. 3. if -mno-unaligned-access is given you should not use accesses that are larger than the struct's __attribute__((alignment(x))) 4. otherwise if unaligned accesses are allowed, you may generate an unaligned ldr/str instruction. Note: please do not use ldmia/stmia with unaligned addresses, because that does still segfault even in ARMv7. (that may be handled by a Linux IRQ but not for other O/S like eCos)
[Bug fortran/42607] add information about how to compile a module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42607 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- What should we do with this PR?
[Bug lto/57703] New: Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Bug ID: 57703 Summary: Assembler function definition moved to a different ltrans then call Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: marxin.liska at gmail dot com SandboxSyscall calls SyscallAsm that is an assembler function defined in the same file: syscall.cc. dump grep: grep SyscallAsm *: out/Release/nacl_helper.ltrans1.047i.inline:call SyscallAsm out/Release/nacl_helper.ltrans1.047i.inline:call SyscallAsm out/Release/nacl_helper.ltrans0.s:.type SyscallAsm, @function out/Release/nacl_helper.ltrans0.s:SyscallAsm:.cfi_startproc out/Release/nacl_helper.ltrans0.s:9:.size SyscallAsm, 9b-SyscallAsm out/Release/nacl_helper.ltrans1.s:call SyscallAsm out/Release/nacl_helper.ltrans1.045i.cp:call SyscallAsm Linker error: nacl_helper.ltrans1.ltrans.o: In function `playground2::SandboxSyscall(int, long, long, long, long, long, long)': nacl_helper.ltrans1.o:(.text+0x4503): undefined reference to `SyscallAsm' /home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: nacl_helper.ltrans1.ltrans.o: relocation R_X86_64_PC32 against undefined symbol `SyscallAsm' can not be used when making a shared object; recompile with -fPIC /home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: final link failed: Bad value collect2: error: ld returned 1 exit status Dumps link: https://docs.google.com/file/d/0B0pisUJ80pO1eFltWU9NUUZkaGM/edit?usp=sharing When compiled with --param lto-partitions=1 no problem is encountered.
[Bug fortran/51535] Optimization problem with -finit-real=snan at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51535 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I can reproduce it with gfortran 4.7.3 and '-O2 -ffpe-trap=zero,overflow,invalid -finit-real=snan -mfpmath=387', but not with 4.8.1 nor trunk. Could this PR be closed as FIXED?
[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Since I don't access to a box (linux or not) allowing -static, I cannot reproduce the segmentation fault. Is the array test in comment #0 still failing?
[Bug fortran/52328] Wrong line in warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52328 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Works for me too from 4.4 to trunk (4.9): write (*,*) HELLO WORLD 1 Warning: Nonconforming tab character at (1) Closing as WORKSFORME. Please reopen if I am wrong.
[Bug middle-end/57670] Member-pointer calls should not be redirected to builtin_unreachable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57670 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-06/msg01403.htm ||l --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org --- The subject of the email should have been Do not turn member pointer CALLS to builtin_unreachable but nevertheless I have submitted a fix to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01403.html
[Bug libstdc++/57704] New: std::char_traitschar::lt is not standards-compliant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57704 Bug ID: 57704 Summary: std::char_traitschar::lt is not standards-compliant Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tudorb at fb dot com Created attachment 30356 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30356action=edit simple example to illustrate the bug The C++11 standard says in 21.2.3.1 (struct char_traitschar): The two-argument members eq and lt shall be defined identically to the built-in operators == and for type unsigned char. However, this is not the case if char is signed (tested using gcc 4.1.2, 4.6.2, and 4.7.1 on x86_64, but the trunk version of char_traits.h is the same); char_traitschar::lt compares the two values as char, not as unsigned char. The attached program should print 1 twice when this bug is fixed.
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #28 from Martin Liška marxin.liska at gmail dot com --- Patch solved the problem for chromium ;) I will test libreoffice tomorrow. (In reply to Martin Jambor from comment #27) Created attachment 30355 [details] Proposed patch I'd suggest this (yet untested) patch.
[Bug libstdc++/57704] std::char_traitschar::lt is not standards-compliant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57704 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This is LWG 467, thus it applies to C++98 too. Since, moreover, at the moment there are no internal uses in the library of char_traitschar::lt, I think the straightforward tweak can be implemented unconditionally and safely.
[Bug libstdc++/57704] std::char_traitschar::lt is not standards-compliant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57704 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0
[Bug c/57692] FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692 Steve Ellcey sje at gcc dot gnu.org changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #1 from Steve Ellcey sje at gcc dot gnu.org --- I see this on my MIPS targets as well, I think it is on all platforms.
[Bug c/57692] FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I see this on my MIPS targets as well, I think it is on all platforms. I think so, or at least most of them. This is why I did not fill the Target field.
[Bug tree-optimization/57701] Incorrect optimisation of inlined function with inline assembly when cross-compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701 --- Comment #2 from sqweek sqweek at gmail dot com --- Sorry! The constraints were actually the first place I looked for a problem, apparently my inexperience with assembly made me blind to the mistake :( Thanks for your time.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #15 from Allan McRae allan at archlinux dot org ---
with -ffreestanding
LC_ENTER foo.c
LC_RENAME command-line
LC_ENTER foo.h
LC_LEAVE 0x0
LC_RENAME foo.c
- correct output printed here
LC_LEAVE 0x0
so std-predef.h is not included.
I tried with -include foo.h and a breakpoint in push_command_line_include... I
just stepped through from that breakpoint and saw cpp_push_default_include
being called for both stdc-predef.h and foo.h. That also gives the correct
output.
# gcc-4.9 -include foo.h foo.c
foo.c: In function ‘main’:
foo.c:1:21: error: expected expression before ‘}’ token
int main() { return }
[Bug c/57692] FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692
--- Comment #3 from Balaji V. Iyer bviyer at gmail dot com ---
[sorry, I accidentally hit the send...let's try this again...]
Hello Dominique Steve,
From what I can tell, this looks like a stack overflow issue. When I
try this change below, it seem to work fine. This testcase works as-is in
my SUSE x86_64 machine.
Alternatively, if I change the #define NUMBER to like 10 or 20 from 100, it
seem to work fine without the change below.
Please let me know if either of the two changes is OK and I will submit a
patch and check the change in.
Thanks,
Balaji V. Iyer.
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/gather_scatter.c
b/gcc/test
index 9cb16e1..ad05030 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/gather_scatter.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/gather_scatter.c
@@ -6,11 +6,11 @@
#include stdio.h
#endif
+float array4[NUMBER][NUMBER][NUMBER][NUMBER];
int main(void)
{
int array[NUMBER][NUMBER], array2[NUMBER], array3[NUMBER], x = 0, y;
- int x_correct, y_correct, ii, jj = 0;
- float array4[NUMBER][NUMBER][NUMBER][NUMBER];
+ int x_correct, y_correct, ii, jj = 0, kk = 0, ll = 0;
for (ii = 0; ii NUMBER; ii++)
{
for (jj = 0; jj NUMBER; jj++)
@@ -20,7 +20,10 @@ int main(void)
array3[ii]= 3;
}
}
On Mon, Jun 24, 2013 at 11:07 PM, Balaji V. Iyer bvi...@gmail.com wrote:
Hello Dominique and Steve,
On Mon, Jun 24, 2013 at 7:24 PM, dominiq at lps dot ens.fr
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-24
Ever confirmed|0 |1
--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I see this on my MIPS targets as well, I think it is on all platforms.
I think so, or at least most of them. This is why I did not fill the
Target
field.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug fortran/42607] add information about how to compile a module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42607 --- Comment #12 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #11) What should we do with this PR? See my comment #1 and #10. I think that the PR should be closed with WONTFIX (because gcc does not have INDIFFERENCE). Contributing documentation for gfortran is the easiest way to get involved with its development. Yet, none of the individuals, who seem to think that .mod file creation needs to be document, have step forward to write the doc.
[Bug c/57692] FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692 --- Comment #4 from Balaji V. Iyer bviyer at gmail dot com --- Hello Dominique and Steve, On Mon, Jun 24, 2013 at 7:24 PM, dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I see this on my MIPS targets as well, I think it is on all platforms. I think so, or at least most of them. This is why I did not fill the Target field. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug c++/57699] Disable empty parameter list misinterpretation in libstdc++ headers when !defined(NO_IMPLICIT_EXTERN_C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- eCos is open source so that should be fixed. The easy fix for the libstdc++ headers is to use void as the argument.
