[Bug 45774] (web) gcc-bugs mail subject issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45774 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Severity|normal |trivial --- Comment #1 from Frédéric Buclin LpSolit at netscape dot net 2010-09-24 06:04:05 UTC --- Well, the [Bug comp/NNN] format is not understood by Bugzilla by default when parsing incoming emails (when you reply by email instead of opening your web browser). The GCC extension I wrote recognizes this format, but I'm in favor on moving to a format which Bugzilla can recognize natively. And per my discussion with admins, we agreed to go this way. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45758] (middle-end) [4.6 Regression] ICE in expr_invariant_in_loop_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45758 --- Comment #6 from Sebastian Pop spop at gcc dot gnu.org 2010-09-24 06:10:31 UTC --- Author: spop Date: Fri Sep 24 06:10:23 2010 New Revision: 164582 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164582 Log: Fix PR45758: reset scevs before Graphite. 2010-09-24 Sebastian Pop sebastian@amd.com PR middle-end/45758 * graphite.c (graphite_initialize): Call scev_reset. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45766] (web) New Bugzilla UI changes horizontal items to vertical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45766 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added CC||Joost.VandeVondele at pci ||dot uzh.ch --- Comment #7 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-09-24 06:27:25 UTC --- (In reply to comment #5) You have to shift+reload to clear the old CSS files from your browser cache. not quite intuitive, but works great... -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45544] (c++) ICE: in sese_adjust_liveout_phis, at sese.c:633
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45544 --- Comment #4 from Sebastian Pop spop at gcc dot gnu.org 2010-09-24 06:34:15 UTC --- I cannot reproduce the bug. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45775] (c++) New: Private templated classes/structs inside a class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45775 Summary: Private templated classes/structs inside a class. Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: liran...@gmail.com Created attachment 21874 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21874 Failing code Using GCC 4.4.3, and the attached source code, GCC does not error that the access to A::BT is illegal. According to the C++ spec: 11.8 Nested classes [class.access.nest] 1 A nested class is a member and as such has the same access rights as any other member. The members of an enclosing class have no special access to members of a nested class; the usual access rules (Clause 11) shall be obeyed. Note that A::C is erroring correctly. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45775] (c++) Private templated classes/structs inside a class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45775
--- Comment #1 from Liran Nuna liranuna at gmail dot com 2010-09-24 06:50:29
UTC ---
Accidentally attached wrong source file:
#include cstdio
class A
{
private:
template unsigned T
struct B
{
};
struct C
{
};
public:
template unsigned T
BT getAb()
{
return BT();
}
C getAc()
{
return C();
}
};
templateunsigned T
void print_private_template(const A::BT ab)
{
printf(%d\n, T);
}
void print_private_class(const A::C ac)
{
printf(something\n);
}
int main(int, char**)
{
A a;
print_private_template(a.getAb42());
print_private_class(a.getAc());
return 0;
}
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug 45766] (web) New Bugzilla UI changes horizontal items to vertical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45766 --- Comment #8 from Frédéric Buclin LpSolit at netscape dot net 2010-09-24 06:52:41 UTC --- (In reply to comment #7) not quite intuitive, but works great... Well, blame your web browser. :) More seriously, Bugzilla 4.0 will be able to inform your web browser that the CSS files changed on the server and that it needs to reload them instead of loading them from the cache. So the next time that we upgrade, this shouldn't be a problem anymore. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45776] (fortran) New: Full implementation of variable definition contexts (and related checks)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45776 Summary: Full implementation of variable definition contexts (and related checks) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: do...@gcc.gnu.org Since http://gcc.gnu.org/ml/fortran/2010-09/msg00397.html, there is a new routine to check definability of variables and pointers in one place (expr.c:gfc_check_vardef_context). This should be called from all places mentioned in the standard as variable definition context (F2008, 16.6.7) and pointer association context (F2008, 16.6.8). The pointer association contexts should already be implemented, but not all variable definition contexts. Missing are the IO related ones (items 5-10 of the list in 16.6.7) and the ones related to co-array locks (items 14 and 15). These should also be implemented. For instance, the following invalid program is accepted: module m implicit none integer, protected :: a character(len=128), protected :: str end module m program main use :: m integer, parameter :: b = 42 character(len=128) :: myStr myStr = '5' read(myStr, *) a read(myStr, *) b write(str, *) 5 end program main Note that the last line (write to internal PROTECTED variable) was also accepted before the definability check rework. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45776] (fortran) Full implementation of variable definition contexts (and related checks)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45776 Daniel Kraft domob at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.24 08:06:49 date|| Ever Confirmed|0 |1 --- Comment #1 from Daniel Kraft domob at gcc dot gnu.org 2010-09-24 08:06:49 UTC --- Taking this. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 38936] (fortran) F2003: ASSOCIATE construct / improved SELECT TYPE (a=expr)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936 --- Comment #16 from Daniel Kraft domob at gcc dot gnu.org 2010-09-24 08:10:38 UTC --- The last commit partially implemented the missing definability checks also for ASSOCIATE names. For the missing pieces, I opened PR 45776. So here remains the missing pieces for ASSOCIATE to strings and derived-types. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 44242] (target) vms-crt0*.c should compile with gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44242 --- Comment #2 from gingold at gcc dot gnu.org gingold at gcc dot gnu.org 2010-09-24 08:46:39 UTC --- Author: gingold Date: Fri Sep 24 08:46:36 2010 New Revision: 164587 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164587 Log: 2010-09-09 Tristan Gingold ging...@adacore.com PR target/44242 * config/vms/vms-crt0-64.c: Removed. * config/vms/vms-crt0.c: Removed. * config/vms/vms-psxcrt0-64.c: Removed. * config/vms/vms-psxcrt0.c: Removed. * config/vms/vms-ucrt0.c: New file. * config/vms/t-vms64: Removed. * config/vms/t-vms (VMS_EXTRA_PARTS): Uncomment it. Remove DECC. Use $(GCC_FOR_TARGET) to build pcrt0.o and vcrt0.o * config.gcc (alpha-dec-vms): Use t-vms. Added: trunk/gcc/config/vms/vms-ucrt0.c Removed: trunk/gcc/config/vms/t-vms64 trunk/gcc/config/vms/vms-crt0-64.c trunk/gcc/config/vms/vms-crt0.c trunk/gcc/config/vms/vms-psxcrt0-64.c trunk/gcc/config/vms/vms-psxcrt0.c Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/vms/t-vms -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45774] (web) gcc-bugs mail subject issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45774 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-24 09:18:42 UTC --- Hm, I guess we just need to get used to it, but it indeed makes my scanning of incoming bug mails harder. Maybe bugzilla can be taught to recognize this natively instead? -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45110] (debug) GCC does not emit DW_AT_object_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45110 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-09-24 09:20:22 UTC --- Fixed. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45686] (bootstrap) Building rev. 164285 fails with --enable-checking=all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45686 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-09-24 09:21:30 UTC --- Fixed. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45774] (web) gcc-bugs mail subject issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45774 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-09-24 09:23:07 UTC --- Jakub makes a good point about consistency with changelogs. Now that the extension is written and comp/NNN mails are understood (as I tested against bugzilla-test) is the only reason to change format because you prefer it? -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45775] (c++) Private templated classes/structs inside a class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45775
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||redi at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2010-09-24
09:35:15 UTC ---
Your analysis is incorrect, A::BT is not accessible because it's a template.
The bug is that template functions do not obey access control.
If you make print_private_class a template then it can access A::C
templateunsigned T
void print_private_class(const A::C ac)
{
printf(something\n);
}
int main(int, char**)
{
A a;
print_private_class0(a.getAc());
return 0;
}
This is a dup of PR c++/41437
*** This bug has been marked as a duplicate of bug 41437 ***
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug 41437] (c++) No access control for classes in template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||liranuna at gmail dot com --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-09-24 09:35:15 UTC --- *** Bug 45775 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 45774] (web) gcc-bugs mail subject issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45774 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.24 10:05:44 date|| AssignedTo|unassigned at gcc dot |LpSolit at netscape dot net |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Frédéric Buclin LpSolit at netscape dot net 2010-09-24 10:05:44 UTC --- (In reply to comment #3) Now that the extension is written and comp/NNN mails are understood (as I tested against bugzilla-test) is the only reason to change format because you prefer it? Yes. :) But my preference is because that's what Bugzilla understands with no code change. But I will revert it to its old behavior. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/45774] gcc-bugs mail subject issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45774 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Frédéric Buclin LpSolit at netscape dot net 2010-09-24 10:08:47 UTC --- Old format restored. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/45774] gcc-bugs mail subject issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45774 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2010-09-24 10:12:52 UTC --- Thanks. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug lto/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-09-24 10:33:13 UTC --- (In reply to comment #3) The issue here is of course that LTO re-computes TYPE_CANONICAL and the FE sets it in a way that the above situation is not detected as non-trivial conversion. Does the fix need to be done in the FE, or will this be addressed by changes to LTO? Actually, looks like there might be some vaguely related issue here in the FE, which I'll open in another PR. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45777] New: Missing temporary ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45777 Summary: Missing temporary ? Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch this one seems like a missing temporary: MODULE M1 TYPE T1 INTEGER, DIMENSION(:), ALLOCATABLE :: data END TYPE T1 CONTAINS SUBROUTINE S1(T,d) INTEGER, DIMENSION(:), POINTER :: d TYPE(T1), POINTER :: T d(1:5)=T%data(3:7) END SUBROUTINE END MODULE USE M1 TYPE(T1), POINTER :: T INTEGER, DIMENSION(:), POINTER :: d ALLOCATE(T) ALLOCATE(T%data(10)) T%data=(/(i,i=1,10)/) d=T%data(5:9) CALL S1(T,d) IF (ANY(d.NE.(/3,4,5,6,7/))) CALL ABORT() DEALLOCATE(T%data) DEALLOCATE(T) END -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45777] Missing temporary ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45777 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Known to fail||4.3.0, 4.4.0, 4.5.0, 4.6.0 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-09-24 10:45:28 UTC --- This was inspired by PR45586 (what does the restrict attribute on a component of a type mean?) -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug lto/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-09-24 10:46:08 UTC --- (In reply to comment #5) Actually, looks like there might be some vaguely related issue here in the FE, which I'll open in another PR. See PR45777 -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug bootstrap/44231] bootstrap should pass -B prev-lto-plugin/.libs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44231 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-24 11:16:54 UTC --- Obsoleted by the copy-up of lto-plugin to gcc/ -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug tree-optimization/28632] VRP should understand bitwise OR and AND
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2010-09-24 11:30:52 UTC --- Fixed. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45143] [F2008,corrig1] Endless loop with unlimited edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45143 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-24 11:36:29 UTC --- When adding the compilation check, also a gfc_notify_std(GFC_STD_F2008, Fortran 2008: should be added. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45777] Missing temporary ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45777 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-24 11:42:33 UTC --- For what it is worth: gfortran 4.6 and 4.3.2, ifort 11.1, and pgf90 10.1 print 3 4 3 4 3 and thus call abort(). -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #55 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-09-24 11:51:09 UTC --- (In reply to comment #54) Upgrade complete. Have fun! By the way, I think I speak for the GCC project and its users when I say: Merci beaucoup, Frédéric! I hope we weren't very annoying with the little fiddling and bike-shedding. The new bugzilla looks nice. You indeed did something that many of us thought was an impossible feat! -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/45778] New: Append summary information instead of prepending the information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778 Summary: Append summary information instead of prepending the information Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: ka...@gcc.gnu.org The new bugzilla prepends the administrative summary to a bug report, which makes it difficult to find the often times very short messages. In addition, the Tobias Burnus ... changed: line is redundant and could be removed by reformatting the messages Here's an example between *-lines: *** http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45777 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-24 11:42:33 UTC --- For what it is worth: gfortran 4.6 and 4.3.2, ifort 11.1, and pgf90 10.1 print 3 4 3 4 3 and thus call abort(). -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. *** The PR would be easier to read if the formatting is as follows: *** --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-24 11:42:33 UTC --- For what it is worth: gfortran 4.6 and 4.3.2, ifort 11.1, and pgf90 10.1 print 3 4 3 4 3 and thus call abort(). http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45777 What|Removed |Added CC||burnus at gcc dot gnu.org -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. *** -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug tree-optimization/45764] [4.6 Regression] wrong code -O2 vs -O3 (problem in vectorizer???)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45764
--- Comment #3 from Michael Matz matz at gcc dot gnu.org 2010-09-24 13:37:04
UTC ---
The problem is how the alignment for the read accesses is computed.
When we vectorize this data_ref:
ibuf[64 - i] (0 = i 64)
i.e.
ibuf[64 .. 1]
The first access is to ibuf[64], which is aligned to 16 just fine.
But when accessing multiple elements (ibuf[64 .. 61]) the actual
base address will be ibuf[61], which is not aligned to 16 bytes.
I think the code in vectorizable_load that tries to recompute alignment
info from the underlying scalar pointers is incorrect. We currently have:
pi = get_ptr_info (dataref_ptr);
pi-align = TYPE_ALIGN_UNIT (vectype);
if (alignment_support_scheme == dr_aligned)
{
gcc_assert (aligned_access_p (first_dr));
pi-misalign = 0;
}
else if (DR_MISALIGNMENT (first_dr) == -1)
{
TREE_TYPE (data_ref)
= build_aligned_type (TREE_TYPE (data_ref),
TYPE_ALIGN (TREE_TYPE (vectype)));
pi-align = TYPE_ALIGN_UNIT (TREE_TYPE (vectype));
pi-misalign = 0;
}
else
{
TREE_TYPE (data_ref)
= build_aligned_type (TREE_TYPE (data_ref),
TYPE_ALIGN (TREE_TYPE (vectype)));
pi-misalign = DR_MISALIGNMENT (first_dr);
}
dataref_ptr will be the vector pointer. One problem is that for the
testcase alignment_support_scheme is set to dr_aligned. That is because
DR_MISALIGNMENT of first_dr is zero. But first_dr is in terms of the scalar
type, so it seems problematic to use that to assess if the vectorized
access is also aligned. OTOH that is historic code.
But even if we would fix that (set alignment_support_scheme to
dr_unaligned_supported) the code above would do the wrong thing.
DR_MISALIGNMENT (first_dr) is zero, so pi-align would remain at the
(large) alignment of the vector type, and it's misalignment (which was with
respect to the smaller scalar type) would be copied over, also be zero,
and therefore wrong.
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug bootstrap/45751] [4.6 Regression] Bootstrap failure: at stage 1 xgcc segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45751 --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org 2010-09-24 14:06:40 UTC --- Author: iains Date: Fri Sep 24 14:06:35 2010 New Revision: 164592 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164592 Log: PR bootstrap/45751 * gcc/config/darwin-driver.c (darwin_default_min_version): Adjust size passed to memcpy in two places. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-driver.c -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/45778] Append summary information instead of prepending the information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-24 14:19:47 UTC --- I like the fact that the bugzilla URL is topmost, that no longer requires me scrolling down. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug tree-optimization/45764] [4.6 Regression] wrong code -O2 vs -O3 (problem in vectorizer???)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45764 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-24 14:22:23 UTC --- It looks like when vectorizing with negative step the alignment needs to be computed differently. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45234] [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234 --- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org 2010-09-24 14:37:06 UTC --- Author: jakub Date: Fri Sep 24 14:37:02 2010 New Revision: 164593 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164593 Log: PR middle-end/45234 * rtl.h (enum global_rtl_index): Add GR_VIRTUAL_PREFERRED_STACK_BOUNDARY. (LAST_VIRTUAL_POINTER_REGISTER): Define. (virtual_preferred_stack_boundary_rtx, VIRTUAL_PREFERRED_STACK_BOUNDARY_REGNUM): Define. (LAST_VIRTUAL_REGISTER): Increase by one. (REGNO_PTR_FRAME_P): Use LAST_VIRTUAL_POINTER_REGISTER instead of LAST_VIRTUAL_REGISTER. * function.c (instantiate_new_reg): Handle virtual_preferred_stack_boundary_rtx. * emit-rtl.c (init_virtual_regs): Handle VIRTUAL_PREFERRED_STACK_BOUNDARY_REGNUM. (init_emit_regs): Initialize virtual_preferred_stack_boundary_rtx. * explow.c (round_push): If crtl-preferred_stack_boundary is smaller than MAX_SUPPORTED_STACK_ALIGNMENT, use virtual_preferred_stack_boundary_rtx alignment instead of crtl-preferred_stack_boundary alignment. (allocate_dynamic_stack_space): Use CONST_INT_P and REG_P macros. Never decrease crtl-preferred_stack_boundary, use crtl-preferred_stack_boundary or MAX_SUPPORTED_STACK_ALIGNMENT instead of PREFERRED_STACK_BOUNDARY. Don't modify stack_pointer_delta in dynamic allocation, even when size is constant. (probe_stack_range, anti_adjust_stack_and_probe): Use CONST_INT_P macro. * print-rtl.c (print_rtx): Handle VIRTUAL_PREFERRED_STACK_BOUNDARY_REGNUM. * config/alpha/alpha.h (NONSTRICT_REG_OK_FP_BASE_P): Use LAST_VIRTUAL_POINTER_REGISTER instead of LAST_VIRTUAL_REGISTER. * config/frv/frv.c (frv_emit_movsi): Likewise. * config/arm/arm.c (thumb1_legitimate_address_p): Likewise. * config/rs6000/rs6000.c (virtual_stack_registers_memory_p): Likewise. * gcc.dg/torture/stackalign/alloca-6.c: New test. * gcc.target/i386/pr45234.c: New test. Revert: 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45234 * calls.c (expand_call): Make sure that all variable sized adjustments are multiple of preferred stack boundary after stack alignment. Added: trunk/gcc/testsuite/gcc.dg/torture/stackalign/alloca-6.c trunk/gcc/testsuite/gcc.target/i386/pr45234.c Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/config/alpha/alpha.h trunk/gcc/config/arm/arm.c trunk/gcc/config/frv/frv.c trunk/gcc/config/rs6000/rs6000.c trunk/gcc/emit-rtl.c trunk/gcc/explow.c trunk/gcc/function.c trunk/gcc/print-rtl.c trunk/gcc/rtl.h trunk/gcc/testsuite/ChangeLog -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug bootstrap/45751] [4.6 Regression] Bootstrap failure: at stage 1 xgcc segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45751 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Iain Sandoe iains at gcc dot gnu.org 2010-09-24 14:57:06 UTC --- fixed -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45234] [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2010-09-24 15:02:06 UTC --- Author: jakub Date: Fri Sep 24 15:01:53 2010 New Revision: 164595 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164595 Log: Revert: 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45234 * calls.c (expand_call): Make sure that all variable sized adjustments are multiple of preferred stack boundary after stack alignment. * gcc.dg/torture/stackalign/alloca-5.c: Remove. Removed: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/stackalign/alloca-5.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/calls.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45234] [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234 --- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2010-09-24 15:07:40 UTC --- Author: jakub Date: Fri Sep 24 15:07:36 2010 New Revision: 164596 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164596 Log: Revert: 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45234 * calls.c (expand_call): Make sure that all variable sized adjustments are multiple of preferred stack boundary after stack alignment. * gcc.dg/torture/stackalign/alloca-5.c: Remove. Removed: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/stackalign/alloca-5.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/calls.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45234] [4.4/4.5 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P2 CC||jakub at gcc dot gnu.org Known to work||4.6.0 Summary|[4.4/4.5/4.6 Regression]|[4.4/4.5 Regression] ICE in |ICE in expand_call, at |expand_call, at |calls.c:2845 when passing |calls.c:2845 when passing |aligned function argument |aligned function argument |from unaligned stack after |from unaligned stack after |alloca |alloca Known to fail|4.6.0 | --- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org 2010-09-24 15:11:33 UTC --- Should be fixed now on the trunk, on 4.4 and 4.5 I've so far reverted the old patch, will wait some time before backporting the new patch. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c/45404] /*code-comment*/ related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45404 --- Comment #2 from jnspaulsson at gmail dot com 2010-09-24 15:33:28 UTC --- sorry, I may just have been confused, but the comments did not help me at least very much. Just tried to help a bit.. :-) If you think it seems right, please accept my apologies... /JP 2010/9/24 pinskia at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45404 Andrew Pinski pinskia at gcc dot gnu.org changed: What |Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed| |2010.09.23 22:57:41 date| | Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-09-23 22:57:41 UTC --- Are you sure about that? execute_cleanup_cfg_post_optimizing is part of the pass_cleanup_cfg_post_optimizing pass which is done in the following order: NEXT_PASS (pass_cleanup_cfg_post_optimizing); NEXT_PASS (pass_warn_function_noreturn); NEXT_PASS (pass_expand); -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c/45779] New: pointer difference error/ptrdiff_t representability
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45779
Summary: pointer difference error/ptrdiff_t representability
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akla...@rumms.uni-mannheim.de
Note: initially found on gcc 4.3.2, confirmed on 4.6.0 20100924 from svn.
Consider the following program:
code
/* test.c */
#includeassert.h
#includeinttypes.h
#includestddef.h
#includestdio.h
#includestdlib.h
int main(int argc, char ** argv) {
printf(ptrdiff_t max: %ju, size_t max: %ju\n, (uintmax_t)
PTRDIFF_MAX, (uintmax_t) SIZE_MAX);
assert (argc 1);
size_t size = atoll(argv[1]);
printf(requested array size: %zu\n, size);
assert (size 0);
uint16_t * array = malloc(size * sizeof(*array));
assert (array != NULL);
printf(array one-past-end/start difference: %td\n,
array[size] - array[0]);
}
/code
$ gcc -std=c99 -pedantic -Wall -Wextra test.c
$ ./a.out 12
ptrdiff_t max: 2147483647, size_t max: 4294967295
requested array size: 12
array one-past-end/start difference: -947483648
The output -947483648 violates the C99 standard, it should be 12.
This program was compiled and run on an IA-32 host with 2.5 GiB memory.
The pointer returned by the successful call to malloc() points to an array of
12 uint16_t's. In the present case, the number 12 is smaller
than PTRDIFF_MAX and thus representable by the ptrdiff_t type. Hence, by the
C99 standard, 6.5.6p9, the expression array[size] - array[0] above is defined
to have type ptrdiff_t and value 12.
Note that if one replaced uint16_t with char in the above code and called the
program with argument 24 (a number larger than PTRDIFF_MAX), the
behaviour would be undefined. Therefore I suspect that, internally, gcc first
calculates the value of array[size] - array[0] as if array had type
pointer-to-char and then erroneously interprets the result as a negative 32-bit
2's complement signed integer, which it then divides by 2 (that is,
sizeof(uint16_t)) with a signed integer division.
Best regards,
Alexander
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug tree-optimization/45764] [4.6 Regression] wrong code -O2 vs -O3 (problem in vectorizer???)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45764
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu.org,
||spop at gcc dot gnu.org
--- Comment #5 from Michael Matz matz at gcc dot gnu.org 2010-09-24 16:06:03
UTC ---
This patch will set the correct misalign info on that data-reference:
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 164476)
+++ tree-vect-data-refs.c (working copy)
@@ -900,6 +900,19 @@ vect_compute_data_ref_alignment (struct
|| (TREE_CODE (base) == VAR_DECL
DECL_ALIGN (base) = TYPE_ALIGN (vectype)));
+ /* If this is a backward running DR then first access in the larger
+ vectype actually is N-1 elements before the address in the DR.
+ Adjust misalign accordingly. */
+ if (tree_int_cst_compare (DR_STEP (dr), size_zero_node) 0)
+{
+ tree offset = ssize_int (TYPE_VECTOR_SUBPARTS (vectype) - 1);
+ /* DR_STEP(dr) is the same as -TYPE_SIZE of the scalar type,
+ otherwise we wouldn't be here. */
+ offset = fold_build2 (MULT_EXPR, ssizetype, offset, DR_STEP (dr));
+ /* PLUS because DR_STEP was negative. */
+ misalign = size_binop (PLUS_EXPR, misalign, offset);
+}
+
/* Modulo alignment. */
misalign = size_binop (FLOOR_MOD_EXPR, misalign, alignment);
Unfortunately this will later result in an ICE during peeling. It
wants to peel these data-refs that now are known misaligned, and during cost
computation changes data-refs that have the same alignment state to be
aligned too (makes sense because those data-refs will also be aligned when
the to-be-peeled DR is aligned).
Unfortunately the STMT_VINFO_SAME_ALIGN_REFS contains bogus reference,
because ultimately the distance vectors are wrong:
(compute_affine_dependence
(stmt_a = D.2097_46 = ibuf[D.2094_43];)
(stmt_b = D.2100_64 = ibuf[D.2099_63];)
(subscript_dependence_tester
(analyze_overlapping_iterations
(chrec_a = {64, +, -1}_2)
(chrec_b = {64, +, 1}_2)
(analyze_siv_subscript
(analyze_subscript_affine_affine
(overlaps_a = [0]
(overlaps_b = [0]
(overlap_iterations_a = [0]
(overlap_iterations_b = [0]
(build_classic_dist_vector
dist_vector = ( 0 )
So, we have two DRs running in opposite directions, which happen to
have the initial element in common (index 64), but afterwards diverge and
have nothing in common anymore. So overlap_iterations_a/b is correct.
But the distance vector is 0, meaning 'same in all iterations'. That
is used to initialize STMT_VINFO_SAME_ALIGN_REFS in
vect_find_same_alignment_drs .
Obviously the distance vector should be unknown (it could be a chrec, if
we really want, namely {0, +, 2}_2, but we don't do anything with such
distances). I tried to determine why it is wrong, it's ultimately
coming from SUB_DISTANCE of that DDR, computed like so
(compute_subscript_distance):
subscript = DDR_SUBSCRIPT (ddr, i);
cf_a = SUB_CONFLICTS_IN_A (subscript);
cf_b = SUB_CONFLICTS_IN_B (subscript);
fn_a = common_affine_function (cf_a);
fn_b = common_affine_function (cf_b);
if (!fn_a || !fn_b)
{
SUB_DISTANCE (subscript) = chrec_dont_know;
return;
}
diff = affine_fn_minus (fn_a, fn_b);
if (affine_function_constant_p (diff))
SUB_DISTANCE (subscript) = affine_function_base (diff);
else
SUB_DISTANCE (subscript) = chrec_dont_know;
And this is baffling me a bit. How could it be correct to
determine a distance vector from only the conflict functions? Doing so
ignores all non-conflicting accesses, although they can (and indeed here do)
influence the distance too.
CCing Zdenek and Sebastian, maybe they have some insight in the latter
problem, as those aren't really related to the vectorizer.
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug fortran/45777] Missing temporary ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45777 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2010.09.24 16:14:05 date|| Ever Confirmed|0 |1 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-24 16:14:05 UTC --- With Crayftn, there is no abort. Thinking a bit about the program, I believe it is valid, i.e. gfortran has a wrong-code bug. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45741] [4.6 Regression] ICE: SIGSEGV in string_constant (expr.c:9863) when parsing memcmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45741 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added Last reconfirmed|2010-09-21 17:37:53 |2010-09-24 17:37:53 date|| --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2010-09-24 16:24:53 UTC --- Author: hubicka Date: Fri Sep 24 16:24:45 2010 New Revision: 164602 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164602 Log: PR tree-optimization/45738 PR tree-optimization/45741 * expr.c (string_constant): Allow CONST_DECL too; check that DECL_INITIAL is set. * varpool.c (const_value_known_p): Only look into VAR_DECL and CONST_DECL. * gcc.c-torture/compile/pr45741.c: New. * gfortran.fortran-torture/compile/pr45738.f90: New. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr45771.c trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr45738.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/varpool.c -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45738] [4.6 Regression] ICE: tree check: expected var_decl, have debug_expr_decl in const_value_known_p, at varpool.c:375
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2010-09-24 16:24:56 UTC --- Author: hubicka Date: Fri Sep 24 16:24:45 2010 New Revision: 164602 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164602 Log: PR tree-optimization/45738 PR tree-optimization/45741 * expr.c (string_constant): Allow CONST_DECL too; check that DECL_INITIAL is set. * varpool.c (const_value_known_p): Only look into VAR_DECL and CONST_DECL. * gcc.c-torture/compile/pr45741.c: New. * gfortran.fortran-torture/compile/pr45738.f90: New. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr45771.c trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr45738.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/varpool.c -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45741] [4.6 Regression] ICE: SIGSEGV in string_constant (expr.c:9863) when parsing memcmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45741 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2010-09-24 16:27:28 UTC --- Fixed. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45738] [4.6 Regression] ICE: tree check: expected var_decl, have debug_expr_decl in const_value_known_p, at varpool.c:375
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2010-09-24 16:28:42 UTC --- Fixed. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 --- Comment #56 from Frédéric Buclin LpSolit at netscape dot net 2010-09-24 16:35:58 UTC --- (In reply to comment #55) By the way, I think I speak for the GCC project and its users when I say: Merci beaucoup, Frédéric! I hope we weren't very annoying with the little fiddling and bike-shedding. Thanks a lot! I really appreciate. :) No worry, the GCC team was very nice. It was a pleasure to work with you all. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45777] Missing temporary ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45777 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-09-24 17:59:40 UTC --- (In reply to comment #3) With Crayftn, there is no abort. that also holds for NAG and g95, BTW. Thinking a bit about the program, I believe it is valid, i.e. gfortran has a wrong-code bug. yes, I also think this testcase is valid. One little bit more tricky (in my mind) is the case where one declares T as 'TYPE(T1) :: T' in S1. It could be that that is not valid. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug lto/43575] lto: ICE upon incompatible type declarations in different TUs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43575 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.0 Resolution||WORKSFORME --- Comment #3 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-24 18:10:22 UTC --- This works for me now. Maybe fixed by the fix for bug 42451. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.09.24 18:33:22 date|| Ever Confirmed|0 |1 --- Comment #4 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-24 18:33:22 UTC --- Waiting for feedback asked for in comment #1. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug tree-optimization/38884] missed FRE with __real and __imag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38884
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2010-09-24
18:38:53 UTC ---
global_res = { 0.0, 0.0, 0.0, 2.0e+0 };
x.0_4 = BIT_FIELD_REF global_res, 32, 0;
x = x.0_4;
return 0;
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug tree-optimization/38885] missed FRE with BIT_FIELD_REF and vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38885
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2010-09-24
18:38:58 UTC ---
global_res = { 0.0, 0.0, 0.0, 2.0e+0 };
x.0_4 = BIT_FIELD_REF global_res, 32, 0;
x = x.0_4;
return 0;
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug c/45780] New: Warning for arithmetic operations involving C99 _Bool variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45780 Summary: Warning for arithmetic operations involving C99 _Bool variable Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ubiz...@gmail.com Pasted from the thread that introduced _Bool in place of GCC bool: quote It can be done ultimately, but as a prerequisite, we should have warnings in -Wextra for all of ? boolvar++; ++boolvar; ? boolvar--; --boolvar; ? boolvar = nonbool; ? boolvar nonbool; boolvar = nonbool; ? boolvar | nonbool; boolvar |= nonbool; ? boolvar ^ nonbool; boolvar ^= nonbool; Fair enough. I have CCed Manuel, perhaps he is interested in this warning. I am not sure it fits in -Wconversion. -Wbool-arith perhaps? It sounds like a warning for a -Wc90-c99-compat or similar option (possibly in a more specific option such as -Wbool-arith) - pure C99 code has little use for such a warning, it's about code that might be compiled either with C99 _Bool, or with C90 unsigned char, and so needs to avoid cases where they are incompatible. Such an option, similar in spirit to -Wtraditional, could also allow you to get warnings in C99 mode for things currently diagnosed with -std=c90 -pedantic. /quote [1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01941.html -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug tree-optimization/38884] missed FRE with __real and __imag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38884 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2010-09-24 18:39:57 UTC --- D.2727_2 = COMPLEX_EXPR dd_1(D), 0.0; sv.i = D.2727_2; d_3 = REALPART_EXPR sv.i; -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug tree-optimization/45781] New: GCC incorrectly puts function in .text.unlikely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45781 Summary: GCC incorrectly puts function in .text.unlikely Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: s...@cup.hp.com Created attachment 21875 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21875 Test case If you compile the attached test case (x.c) with -O2 on ToT sources you will find that init_target_chars is put into .text.unlikely instead of .text. I have verified this on IA64 HP-UX and Linux and on X86 Linux. I do not think this function should be put into .text.unlikely in this case and GCC 4.5 does not do so. It looks like this started with Honza's partial inlining change (r161382). The following patch seems to fix the problem but I am not sure if it is the correct fix or not. Should node-frequency always be set in this case or should the original value be preserved if no attribute is seen. I do not believe node-frequency is uninitialized because if I change the frequeny enum in cgraph.h to make NODE_FREQUENCY_NORMAL a 0 value, the frequency is still set to NODE_FREQUENCY_UNLIKELY_EXECUTED (unless I change predict.c). Index: predict.c === --- predict.c (revision 164573) +++ predict.c (working copy) @@ -2204,6 +2204,8 @@ compute_function_frequency (void) else if (DECL_STATIC_CONSTRUCTOR (current_function_decl) || DECL_STATIC_DESTRUCTOR (current_function_decl)) node-frequency = NODE_FREQUENCY_EXECUTED_ONCE; + else +node-frequency = NODE_FREQUENCY_NORMAL; return; } node-frequency = NODE_FREQUENCY_UNLIKELY_EXECUTED; -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug tree-optimization/38884] missed FRE with __real and __imag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38884 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-24 18:42:45 UTC --- Mine. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug tree-optimization/38885] missed FRE with BIT_FIELD_REF and vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38885 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.24 18:43:43 date|| AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-24 18:43:43 UTC --- Mine. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45780 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.09.24 18:44:45 date|| Version|4.5.2 |unknown Ever Confirmed|0 |1 -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45781 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 Summary|GCC incorrectly puts|[4.6 Regression] GCC |function in .text.unlikely |incorrectly puts function ||in .text.unlikely -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug other/45782] New: bugzilla internal error trying to update existing PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45782 Summary: bugzilla internal error trying to update existing PR Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: rw...@gcc.gnu.org I tried to update bug 45322 and got an Internal error from bugzilla: There was an error sending mail from 'rwild at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org' to 'java-...@gcc.gnu.org':Can't send data What other information do you need? -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug driver/45703] [4.6 regression] --help -v no longer shows linker help
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45703 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.24 19:16:21 date|| AssignedTo|unassigned at gcc dot |rwild at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-24 19:16:21 UTC --- Seems to have been introduced by r158908. Anyway, confirmed, proposed patch at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01901.html. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45783] New: [4.6 Regression] ICE in gfc_add_component_ref, at fortran/class.c:77
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45783 Summary: [4.6 Regression] ICE in gfc_add_component_ref, at fortran/class.c:77 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: anl...@gmx.de Created attachment 21876 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21876 Reduced example Hi all, very recently the attached code broke, leading to: gfcbug110.f90:56.16: p2 =v%inquire_inner_product() 1 Error: Type mismatch in argument 'this' at (1); passed CLASS(vector_class) to CLASS(gradient_class) gfcbug110.f90:33:0: internal compiler error: in gfc_add_component_ref, at fortran/class.c:77 The code compiles fine with 4.5, nagfor 5.2, xlf 13. Cheers, -ha -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c/45784] New: gcc OpenMP - error: invalid controlling predicate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45784
Summary: gcc OpenMP - error: invalid controlling predicate
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com
The test is verifying that the parallel for loop construct may use
a variable of a pointer type in C.
The OpenMP API Version 3.0 (May 2008) describes this usage on page
39 of the document.
Currently the GNU gcc compiler produces the following messages for
this test case:
ISU3417.c: In function 'vla_test':
ISU3417.c:23:25: error: invalid controlling predicate
The PGI, Intel, and Cray compilers compile this test case successfully.
$ cat ISU3417.c
// derived from OpenMP test omp3c/c03_2_5_1_2c.c
#include omp.h
#include stdio.h
#include stdlib.h
#define NT 4
#define INCREMENT 2
#define ARRAY_SIZE INCREMENT*NT
// VLAs are standard only in C99; might as well use a C99-specific data type
// (long long int) while we're testing C99-specific features
void vla_test(int num_threads) {
long long int *ptr, vla[INCREMENT*num_threads];
//long long int *ptr, vla[INCREMENT*40];
int i;
// variable-length array initialized to -1
for (i = 0; i sizeof(vla)/sizeof(vla[0]); i++) {
vla[i] = -1;
}
#pragma omp parallel shared(vla)
{
#pragma omp for schedule(static, 1)
for (ptr = vla; ptr vla + sizeof(vla)/sizeof(vla[0]);
ptr = ptr + INCREMENT)
*ptr = omp_get_thread_num();
}
for (i = 0; i sizeof(vla)/sizeof(vla[0]); i++) {
if (vla[i] != (i % INCREMENT == 0 ? (i/INCREMENT) % num_threads : -1))
{
fprintf(stderr, %s:%i: FAIL - vla[%i] == %lli != %i\n,
__FILE__, __LINE__, i, vla[i],
(i % INCREMENT == 0 ? (i/INCREMENT) % num_threads : -1));
exit(1);
}
}
}
int main(void) {
omp_set_dynamic(0);
omp_set_num_threads(NT);
vla_test(NT);
return 0;
}
$ gcc -c -fopenmp -std=c99 ISU3417.c
ISU3417.c: In function 'vla_test':
ISU3417.c:24:25: error: invalid controlling predicate
$
Other compilers working:
$ pgcc -mp -c ISU3417.c
$ icc -c -openmp ISU3417.c
$ cc -c -omp -V ISU3417.c
/opt/cray/xt-asyncpe/4.4.9/bin/cc: INFO: Compiling for compute nodes running
CLE.
Cray C : Version 7.2.7 (u7267c72242i72182p72540a72002e60006z72540)
Cray C : (x7205r72009w71001t7207)
Cray C : Fri Sep 24, 2010 14:34:26
$
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug fortran/45783] [4.6 Regression] ICE in gfc_add_component_ref, at fortran/class.c:77
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45783 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-09-24 19:51:51 UTC --- Confirmed on x86_64-apple-darwin10 with revision 164583, the test compiles with r164232. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/45782] bugzilla internal error trying to update existing PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45782 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.09.24 19:56:15 date|| Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-09-24 19:56:15 UTC --- I saw this also with a different bug but still with java-...@gcc.gnu.org as the email. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/45785] New: Bugzilla search sometimes fails with an internal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45785 Summary: Bugzilla search sometimes fails with an internal error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 21877 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21877 Internal Server Error In about half of cases I try to search for a bug: http://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_type=allwordscf_known_to_work_type=allwordsquery_format=advancedbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDlongdesc=bit_value_binoplongdesc_type=allwordssubstr I get an internal server error (see attachment). The error page is shown after ~1-2 minutes of waiting. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
Yu Simin silver24k at gmail dot com changed:
What|Removed |Added
CC||silver24k at gmail dot com
--- Comment #26 from Yu Simin silver24k at gmail dot com 2010-09-24 20:21:08
UTC ---
[English is not my native language ...]
In GCC 4.5 or later, both the compilation time and the sizes of the generated
object files is far longer or far larger than MSVC when PCH is enabled in both
of the compilers.
MSVC requires a DUMMY source file eg:dummy.cpp to be used when generating the
PCH file and will generate an object file eg:dummy.obj. But the dummy object
file is not dummy at all. It contains all the common codes generated from the
sources/headers of the PCH.
In GCC, PCH is just preprocess + compiling, no common code (is this case
dllexports) generating. so every compilation unit will have to generate the
codes in the PCH file again and again while MSVC will not generate them once
more.
We may add a flag for example -fgenerate-pch-codes/-fno-generate-pch-codes (or
some pragmas) to make GCC work similar to MSVC.
For example, if we make -fno-generate-pch-codes the default
gcc -O2 -o foo.h.gch foo.h
gcc -O2 -fgenerate-pch-codes -o dummy.o dymmy.cpp # add this to generate the
codes of foo.h to dummy.o
# assuming that other1.cpp/other2.cpp use foo.h.gch
gcc -O2 -o other1.o other1.cpp # no code in foo.h will be generated on other1.o
gcc -O2 -o other2.o other2.cpp # no code in foo.h will be generated on other2.o
...
Here is my patch (picked from my local copy so maybe someting is missing, a bit
different from above and only handle the dllexport case and may have bug for
trunk). with this patch I successfully built wxWidget 2.8.10 trunk (slightly
modified to make PCH enabled for GCC and added a dummy file with my pragma
below), the monolithic DLL seems ok (~9M in size, at least the wxWidget demos
examples work well).
I only care about the compilation time and the size of objects because it make
ld failed to link the wxWidget DLL on my windows box (I do not want to revert
the dllexports change. before this patch is out， I had to link it on 64bit
linux in VirtualBox by a cross toolchain and the generated DLL is ~25MB! This
size explosion seems to be caused by the inline strategy, but I did not look
into it)
I won't have any time to maintain the patch, just hope it will be useful to
help solving the problem finally.
In this patch I've introduced one flag
-fpch-ignore-inline-dllexports (-fno-pch-ignore-inline-dllexports)
and one pragma
#pragma pch_ignore_inline_dllexports on/off
Index: c-family/c-pragma.c
===
--- c-family/c-pragma.c (版本 164605)
+++ c-family/c-pragma.c (工作副本)
@@ -1314,7 +1314,9 @@
if (!flag_preprocess_only)
cpp_register_deferred_pragma (parse_in, GCC, pch_preprocess,
PRAGMA_GCC_PCH_PREPROCESS, false, false);
-
+ cpp_register_deferred_pragma (parse_in, GCC,
pch_ignore_inline_dllexports,
+ PRAGMA_GCC_PCH_IGNORE_INLINE_DLLEXPORTS, false,
false);
+
#ifdef HANDLE_PRAGMA_PACK
#ifdef HANDLE_PRAGMA_PACK_WITH_EXPANSION
c_register_pragma_with_expansion (0, pack, handle_pragma_pack);
Index: c-family/c-pragma.h
===
--- c-family/c-pragma.h (版本 164605)
+++ c-family/c-pragma.h (工作副本)
@@ -47,6 +47,8 @@
PRAGMA_GCC_PCH_PREPROCESS,
+ PRAGMA_GCC_PCH_IGNORE_INLINE_DLLEXPORTS,
+
PRAGMA_FIRST_EXTERNAL
} pragma_kind;
Index: cgraph.h
===
--- cgraph.h(版本 164605)
+++ cgraph.h(工作副本)
@@ -125,6 +125,10 @@
/* True if the function is going to be emitted in some other translation
unit, referenced from vtable. */
unsigned vtable_method : 1;
};
/* Information about the function that needs to be computed globally
Index: tree.h
===
--- tree.h (版本 164605)
+++ tree.h (工作副本)
@@ -2706,6 +2706,13 @@
#define DECL_GIMPLE_REG_P(DECL) \
DECL_COMMON_CHECK (DECL)-decl_common.gimple_reg_flag
+/* To support fkeep-dllexport-inline-functions-in-pch,
+ indicates that the dllexport inline function is defined in PCH */
+#define DECL_DLLEXPORT_INLINE_IN_PCH_P(DECL) \
+ DECL_COMMON_CHECK (DECL)-decl_common.dllexport_inline_in_pch
+
+
struct GTY(()) tree_decl_common {
struct tree_decl_minimal common;
tree size;
@@ -2759,6 +2765,10 @@
unsigned int off_align : 8;
/* 24-bits unused. */
+
+ /* To support fkeep-dllexport-inline-functions-in-pch */
+ unsigned int dllexport_inline_in_pch : 1;
/* DECL_ALIGN. It should have the same size as TYPE_ALIGN. */
unsigned int align;
Index: common.opt
[Bug bootstrap/45737] Bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45737 Steve Ellcey sje at cup dot hp.com changed: What|Removed |Added CC||sje at cup dot hp.com --- Comment #4 from Steve Ellcey sje at cup dot hp.com 2010-09-24 20:33:32 UTC --- I haven't seen this failure but I don't build with GMP and MPFR in my build tree. They are installed on the system instead and I use --with-gmp=DIR and --with-mpfr=DIR on the configure line to point to where they live. Doing the build this way might give you a workaround if it is only the gmp and mpfr files that differ during the bootstrap. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45388] [4.6 Regression] Global constructor not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45388 Steve Ellcey sje at cup dot hp.com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.09.24 21:06:43 date|| CC||sje at cup dot hp.com Ever Confirmed|0 |1 -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c++/34684] Cross DLL Exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34684 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2010-09-24 21:08:50 UTC --- For gcc version 4.5.x and newer mingw/cygwin targets are supporting shared version of libgcc and libstdc++ OOTB. By using them (see option -shared-libgcc/libstdc++) cross-DLL throw/catch is working. The static variant is still not working. This could be solved by using SEH unwinding, which isn't a feature of gcc for 32-bit x86 at the moment. So I close this bug, as there is now a working way to handle this problem -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45783] [4.6 Regression] ICE in gfc_add_component_ref, at fortran/class.c:77
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45783 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin mikael at gcc dot gnu.org 2010-09-24 21:26:41 UTC --- r164338 (2010-09-16) works. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 --- Comment #57 from Tom Tromey tromey at gcc dot gnu.org 2010-09-24 21:34:23 UTC --- Thank you very much for doing this. I am hoping you would also be interested in upgrading the sourceware.org bugzilla installation. It is hosted on the same machine... -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 --- Comment #58 from Frédéric Buclin LpSolit at netscape dot net 2010-09-24 21:39:26 UTC --- (In reply to comment #57) I am hoping you would also be interested in upgrading the sourceware.org bugzilla installation. It is hosted on the same machine... Yup, see http://sourceware.org/bugzilla/show_bug.cgi?id=4790 -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #59 from Steven Bosscher steven at gcc dot gnu.org 2010-09-24 21:49:46 UTC --- This deserves mentioning on gcc.gnu.org. Thanks for the upgrade! -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c++/45770] global access allowance exceeds that of derived class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45770
MichieldeB at aim dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #2 from MichieldeB at aim dot com 2010-09-24 21:53:56 UTC ---
// If the access of locals should be inherited, then the following is a bug.
// g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
// Copyright (C) 2009 Free Software Foundation, Inc.
// This is free software; see the source for copying conditions. There is NO
// warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
class A
{
friend class B;
public:
A(int i) { a = i; }
private:
A() { a = 0; }
int a;
};
class B : private A // making protected will allow local variables A below
{
public:
B(int i) : A () { a = i 1; b = i 1; }
private:
bool b;
};
class C : public B
{
public:
C() : B(4) { ::A foo(3); } // functions of B may have local variables ::A
// but not A
};
template class T, class U class D : private T
{
D(int i) : T(i) { U u; }
};
template class DA,A; // local A gets global access rights
main () { ::A bar(3); } // main may have local variables A
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug c++/45770] global access allowance exceeds that of derived class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45770
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2010-09-24
21:58:44 UTC ---
access of locals
Huh? That is not what I am saying. What I am saying is that A names (inside
C) the injected name in B which is private.
The reason why:
template class T, class U class D : private T
{
D(int i) : T(i) { U u; }
};
template class DA,A; // local A gets global access rights
--- CUT ---
Works is because the names you are using are T and U and not A.
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 --- Comment #60 from Gerald Pfeifer gerald at pfeifer dot com 2010-09-24 21:58:18 UTC --- (In reply to comment #59) This deserves mentioning on gcc.gnu.org. Thanks for the upgrade! Yep, I had asked Frédéric for some input already. :-) -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45388] [4.6 Regression] Global constructor not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45388 --- Comment #5 from Steve Ellcey sje at cup dot hp.com 2010-09-24 22:21:38 UTC --- I have verified that the bug shows up in r163443. Looking at the assembly language differences between 163442 and 163443, both versions have _GLOBAL__I_65535_0__ZN2c12f6Ev, a global routine to call the static initializer (_Z41__static_initialization_and_destruction_0ii), but the new version also has _GLOBAL__I__ZN2c12f6Ev to call the static initializer and this routine is not global. If I change the assembly language code to change the GLOBAL__I__ZN2c12f6Ev function from static (.PARAM) to global (.EXPORT) then the code will compile. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/45785] Bugzilla search sometimes fails with an internal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45785 --- Comment #1 from Frédéric Buclin LpSolit at netscape dot net 2010-09-24 22:40:28 UTC --- Yeah, there seems to be some performance problems with the DB server. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug web/45778] Append summary information instead of prepending the information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778 --- Comment #2 from Steve Kargl sgk at troutmask dot apl.washington.edu 2010-09-24 22:57:01 UTC --- On Fri, Sep 24, 2010 at 02:19:53PM +, rguenth at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-24 14:19:47 UTC --- I like the fact that the bugzilla URL is topmost, that no longer requires me scrolling down. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. I suppose leaving the URL at the top is ok, but reminds me of the evil offense of top posting. I also think that the last four lines quoted above should go away. Do we really need the 150+ byte message tacked onto ever message posted in bugzilla? The following URL shows (at least to me) that the current formatting clutters the actual content. http://gcc.gnu.org/ml/gcc-bugs/2010-09/msg02740.html -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45786] New: Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 Summary: Relational operators .eq. and == are not recognized as equivalent Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: neil.n.carl...@gmail.com The first paragraph of 7.2 in the standard states that The operators , ... always have the same interpretations as the operators .LT., ... Consider the following example: module foo_type private public :: foo, operator(==) type :: foo integer :: bar end type interface operator(.eq.) module procedure eq_foo end interface contains logical function eq_foo (a, b) type(foo), intent(in) :: a, b eq_foo = (a%bar == b%bar) end function end module subroutine use_it (a, b) use foo_type type(foo) :: a, b print *, a == b end subroutine The compiler incorrectly complains (essentially) that it has no == operator for the operands when in fact it should -- it appears that the defined .EQ. operator is not being treated as the same as == in the module. Here's the compiler error: print *, a == b 1 Error: Operands of comparison operator '==' at (1) are TYPE(foo)/TYPE(foo) -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/45388] [4.6 Regression] Global constructor not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45388 --- Comment #6 from Steve Ellcey sje at cup dot hp.com 2010-09-24 23:45:28 UTC --- I have a patch I am testing. It worked on the test case but I haven't fully bootstrapped it. Index: ipa.c === --- ipa.c (revision 164578) +++ ipa.c (working copy) @@ -1480,6 +1480,7 @@ build_cdtor (bool ctor_p, VEC (tree, hea DECL_STATIC_CONSTRUCTOR (fn) = 0; else DECL_STATIC_DESTRUCTOR (fn) = 0; + TREE_PUBLIC (fn) = 1; /* We do not want to optimize away pure/const calls here. When optimizing, these should be already removed, when not optimizing, we want user to be able to breakpoint in them. */ -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug plugins/45787] New: r164531 breaks plugin support on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45787 Summary: r164531 breaks plugin support on x86_64-apple-darwin10 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 Author: jsm28 Date: Wed Sep 22 20:12:06 2010 New Revision: 164531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164531 Log: * common.opt (-assemble, -compile, -coverage, -debug, -dump, -dump=, -dumpbase, -dumpdir, -entry, -entry=, -extra-warnings, -for-assembler, -for-assembler=, -for-linker, -for-linker=, -force-link, -force-link=, -language, -language=, -library-directory, -library-directory=, -no-canonical-prefixes, -no-standard-libraries, -no-warnings, -optimize, -output, -output=, -pass-exit-codes, -pedantic, -pedantic-errors, -pie, -pipe, -prefix, -prefix=, -preprocess, -print-file-name, -print-file-name=, -print-libgcc-file-name, -print-multi-directory, -print-multi-lib, -print-multi-os-directory, -print-prog-name, -print-prog-name=, -print-search-dirs, -print-sysroot, -print-sysroot-headers-suffix, -profile, -save-temps, -shared, -specs, -specs=, -static, -symbolic, -time, -verbose, -param=, -sysroot, coverage, e, u, symbolic): New. (fhelp, fhelp=, ftarget-help, fversion): Make into aliases. * gcc.c (A Short Introduction to Adding a Command-Line Option): Remove comment. (cc1_options): Correct specs for passing down --help, --target-help and --help=*. Add spec for passing down --version. (struct option_map, option_map, target_option_translations, translate_options): Remove. (driver_handle_option): Handle OPT__version, OPT__help, OPT__help_ and OPT__target_help instead of OPT_fversion, OPT_fhelp, OPT_fhelp_ and OPT_ftarget_help. (process_command): Don't call translate_options. Call decode_cmdline_options_to_array before checking for -no-canonical-prefixes using decoded options. * opts-common.c (tm.h): Update comment on #include. (find_opt): Allow abbreviations of long options. (struct option_map, option_map): New. (decode_cmdline_option): Use them instead of hardcoding -Wno, -fno and -mno handling. (target_option_translations): New. (decode_cmdline_options_to_array): Handle TARGET_OPTION_TRANSLATE_TABLE in driver. * opts.c (common_handle_option): Don't handle OPT_fhelp, OPT_ftarget_help, OPT_fhelp_ or OPT_fversion. ada: * gcc-interface/lang.opt (-all-warnings, -include-barrier, -include-directory, -include-directory=, -no-standard-includes, -no-standard-libraries): New. c-family: * c.opt (-all-warnings, -ansi, -assert, -assert=, -comments, -comments-in-macros, -define-macro, -define-macro=, -dependencies, -dump, -dump=, -imacros, -imacros=, -include, -include=, -include-barrier, -include-directory, -include-directory=, -include-directory-after, -include-directory-after=, -include-prefix, -include-prefix=, -include-with-prefix, -include-with-prefix=, -include-with-prefix-after, -include-with-prefix-after=, -include-with-prefix-before, -include-with-prefix-before=, -no-integrated-cpp, -no-line-commands, -no-standard-includes, -no-warnings, -output, -output=, -pedantic, -pedantic-errors, -preprocess, -print-missing-file-dependencies, -trace-includes, -traditional, -traditional-cpp, -trigraphs, -undefine-macro, -undefine-macro=, -user-dependencies, -verbose, -write-dependencies, -write-user-dependencies, no-integrated-cpp, traditional): New. fortran: * gfortranspec.c (lang_specific_driver): Handle OPT__version and OPT__help instead of OPT_fversion and OPT_fhelp. * lang.opt (-all-warnings, -assert, -assert=, -comments, -comments-in-macros, -define-macro, -define-macro=, -dependencies, -dump, -dump=, -include-barrier, -include-directory, -include-directory=, -include-directory-after, -include-directory-after=, -include-prefix, -include-prefix=, -no-line-commands, -no-standard-includes, -output, -output=, -preprocess, -print-missing-file-dependencies, -trace-includes, -undefine-macro, -undefine-macro=, -user-dependencies, -verbose, -write-dependencies, -write-user-dependencies): New. java: * jvspec.c (lang_specific_driver): Handle OPT__help instead of OPT_fhelp. * lang.opt (-CLASSPATH, -all-warnings, -bootclasspath, -classpath, -dependencies, -encoding, -extdirs, -include-directory, -include-directory=, -output-class-directory, -output-class-directory=, -resource, -resource=, -user-dependencies): New. breaks plugin support on x86_64-apple-darwin10. The auto-host.h generated for stage1-gcc contains the
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2010-09-25 00:16:43 UTC --- (In reply to comment #0) The first paragraph of 7.2 in the standard states that The operators , ... always have the same interpretations as the operators .LT., ... Consider the following example: module foo_type private public :: foo, operator(==) Interesting. If you replace == with .eq. in the the above everything works as expected. Interesting**2. If you leave the public statement intact, and change the .eq. in the following to == interface operator(.eq.) module procedure eq_foo end interface everything works as expected. Interesting**3. If you simply remove the private and public statement then everything works as one would expect. And finally, an even more interesting bug. Change the interface statement to interface operator(.eq.) module procedure eq_foo end interface operator(==) This gives h.f90:7.28: end interface operator(==) 1 Error: Expecting 'END INTERFACE OPERATOR (.eq.)' at (1) h.f90:8.10: The above violates C1202. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 --- Comment #2 from neil.n.carlson at gmail dot com 2010-09-25 00:27:24 UTC --- Note also that the problem isn't restricted to .eq./== ; it appears to occur with all the other pairs of equivalent operators: .ne./!=, .lt./, etc. At least the compiler is consistent :) -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug plugins/45787] r164531 breaks plugin support on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45787 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2010-09-25 00:35:32 UTC --- Oddly at both r164530 and r164531, stage3 does build plugin.o in gcc despite the fact that autohost.h has ENABLE_PLUGIN undefined in the second case. However this inhibits the installation of the plugin header directory in lib/gcc/x86_64-apple-darwin10.4.0/4.6.0 at r164531 and later. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 --- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu 2010-09-25 03:00:24 UTC --- On Sat, Sep 25, 2010 at 12:16:53AM +, kargl at gcc dot gnu.org wrote: Interesting**3. If you simply remove the private and public statement then everything works as one would expect. And finally, an even more interesting bug. Change the interface statement to interface operator(.eq.) module procedure eq_foo end interface operator(==) I have a patch that appears to fix this one. I think it is more of a bandaid than a proper fix in that I think .eq. should be simply substituted with == on the input stream during parsing. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #27 from Cesar Strauss cestrauss at gmail dot com 2010-09-25 03:07:42 UTC --- (In reply to comment #25) So I would like to see some proper detailed analysis on object files establishing exactly what constitutes all this bloat and where it comes from before I commit to what might be the wrong path of action. Understood. I'll proceed by performing such a detailed analysis. Also, if you come up with something you want to test, I'll be glad to try any patches you send my way. Regards, Cesar -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 --- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu 2010-09-25 05:57:30 UTC --- On Sat, Sep 25, 2010 at 03:00:37AM +, sgk at troutmask dot apl.washington.edu wrote: On Sat, Sep 25, 2010 at 12:16:53AM +, kargl at gcc dot gnu.org wrote: Interesting**3. If you simply remove the private and public statement then everything works as one would expect. And finally, an even more interesting bug. Change the interface statement to interface operator(.eq.) module procedure eq_foo end interface operator(==) I have a patch that appears to fix this one. I think it is more of a bandaid than a proper fix in that I think .eq. should be simply substituted with == on the input stream during parsing. The patch was committed as svn-commit.tmp: 8 lines, 286 characters. Sendinggcc/fortran/ChangeLog Sendinggcc/fortran/interface.c Sendinggcc/testsuite/ChangeLog Adding gcc/testsuite/gfortran.dg/operator_c1202.f90 Transmitting file data Committed revision 164616. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
