[Bug fortran/54221] Explicit private access specifier signals "unexpected defined but not used [-Wunused-function]" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54221 --- Comment #3 from Tobias Burnus 2012-08-12 09:52:36 UTC --- Author: burnus Date: Sun Aug 12 09:52:33 2012 New Revision: 190325 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190325 Log: 2012-08-12 Tobias Burnus PR fortran/54221 * trans-decl.c (gfc_finish_var_decl, build_function_decl): Fix setting private module vars/procs as TREE_PUBLIC(...) = 0. 2012-08-12 Tobias Burnus PR fortran/54221 * vect/vect-gems.f90: Don't mark module vars as PRIVATE as they appear uninitialized on the RHS. * gfortran.dg/public_private_module_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/public_private_module_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/vect-gems.f90
[Bug fortran/34004] Accepts invalid: Ambigiuous interface with subroutine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34004 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #6 from Mikael Morin 2012-08-12 11:22:39 UTC --- The test in comment #0 is accepted and outputs: $ ./comment_0 1 2 $ Which seems sensible to me. Close as INVALID?
[Bug fortran/39290] Subroutine/function ambiguity in generics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin 2012-08-12 11:27:07 UTC --- It is now rejected with: comment_0.f90:9.21: end subroutine 1 Error: Ambiguous interfaces 'qc' and 'qr' in generic interface 'q' at (1) FIXED?
[Bug tree-optimization/21485] [4.6/4.7/4.8 Regression] missed load PRE, PRE makes i?86 suck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485 --- Comment #52 from wbrana 2012-08-12 12:30:21 UTC --- This bug celebrated 7th anniversary this year. Congratulations!
[Bug fortran/34004] Accepts invalid: Ambigiuous interface with subroutine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34004 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #7 from Tobias Burnus 2012-08-12 12:52:42 UTC --- (In reply to comment #6) > The test in comment #0 is accepted and outputs: > $ ./comment_0 >1 >2 > $ > > Which seems sensible to me. Well the program in comment 0 is invalid in Fortran 2003 but valid in Fortran 2008 (cf. quotes in comment 0 and comment 5.) Thus, we should reject it with -std=f95/f2003 and accept it with -std=f2008 and later. (Cf. PR 45521)
[Bug fortran/39290] Subroutine/function ambiguity in generics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus 2012-08-12 13:01:06 UTC --- F03/0071 passed the WG5 voting (N1806). The latest version (pre WG5 voting) of the IR F03/0071 can be found at ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1805.txt Thus, I concur that it seems to be fixed. However, one could consider to include the two test cases of the IR in the testsuite - besides the invalid one of comment 0, the valid one of question 2 (see IR).
[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423 --- Comment #31 from Oleg Endo 2012-08-12 13:23:24 UTC --- Author: olegendo Date: Sun Aug 12 13:23:20 2012 New Revision: 190326 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190326 Log: PR target/39423 * config/sh/predicates.md (mem_index_disp_operand): Check for arith_reg_operand instead of REG_P. PR target/39423 * gcc.c-torture/compile/pr39423-1.c: New. * gcc.c-torture/compile/pr39423-2.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr39423-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr39423-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug go/54233] New: FAIL: runtime/pprof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54233 Bug #: 54233 Summary: FAIL: runtime/pprof Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: sch...@linux-m68k.org Target: powerpc64-*-* --- FAIL: pprof_test.TestCPUProfile (1.90 seconds) pprof_test.go:83: did not find ChecksumIEEE in the profile FAIL FAIL: runtime/pprof ../../../../libgo/testsuite/gotest: line 465: gotest-timeout: No such file or directory
[Bug fortran/54234] New: -Wconversion or -Wconversion-extra should warn for CMPLX(dp,dp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54234 Bug #: 54234 Summary: -Wconversion or -Wconversion-extra should warn for CMPLX(dp,dp) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org When calling CMPLX with non-default-kind arguments, the compiler should warn about the conversion, i.e. for CMPLX (0.1_dp, 0.1_dp) as the expression is complex(4) while the arguments are REALs with kind=8. There should be no warning for cmplx (complex number). Longer example – compile with -Wconversion -Wconversion-extra. Again, I'd expect a warning for the CMPLX: module fft_mod implicit none integer, parameter :: dp=selected_real_kind(15,300) real(kind=dp), parameter :: pi=3.141592653589793238460 contains subroutine test integer :: x x = int (abs (cmplx(2.3_dp,0.1_dp))) end subroutine test end module fft_mod
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #22 from John David Anglin 2012-08-12 14:30:12 UTC --- Created attachment 27994 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27994 Patch /* synth_mult does an `unsigned int' multiply. As long as the mode is less than or equal in size to `unsigned int' this doesn't matter. If the mode is larger than `unsigned int', then synth_mult works only if the constant value exactly fits in an `unsigned int' without any truncation. This means that multiplying by negative values does not work; results are off by 2^32 on a 32 bit machine. */
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #18 from xunxun 2012-08-12 15:41:35 UTC --- Is the bug related with PR19780?
[Bug fortran/54234] -Wconversion or -Wconversion-extra should warn for CMPLX(dp,dp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54234 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 2012-08-12 16:12:09 UTC --- I believe that a warning is not necessary and in fact should not be issued. The Fortran standard explicitly states that CMPLX returns a complex number with default real kind if the KIND= optional argument is not used.
[Bug middle-end/54193] dump_gimple_assign raw can't handle 4 operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54193 --- Comment #2 from Marc Glisse 2012-08-12 16:20:45 UTC --- Author: glisse Date: Sun Aug 12 16:20:41 2012 New Revision: 190328 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190328 Log: 2012-08-12 Marc Glisse PR middle-end/54193 * gimple-pretty-print.c (dump_ternary_rhs): Handle 4 arguments. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-pretty-print.c
[Bug libstdc++/54185] condition_variable not properly destructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185 --- Comment #7 from Jonathan Wakely 2012-08-12 16:22:28 UTC --- I need a ChangeLog entry before I can commit the change, which needs your name, could you provide a ChangeLog entry? Thanks. Unless I'm mistaken the volatile qualifiers in the testcase don't serve any purpose, so I've removed them from the patch I plan to commit. I have seen it fail, but can't make it fail now, but I think it's useful to commit anyway.
[Bug fortran/54234] -Wconversion or -Wconversion-extra should warn for CMPLX(dp,dp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54234 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig 2012-08-12 16:23:19 UTC --- This is certainly a mistake made by lots of people, so I think a warning would be appropriate.
[Bug middle-end/54193] dump_gimple_assign raw can't handle 4 operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54193 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Marc Glisse 2012-08-12 16:26:03 UTC --- You have to specify a comment when changing the status of a bug from NEW to RESOLVED.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #16 from Gary Funck 2012-08-12 18:08:05 UTC --- Created attachment 27995 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27995 test case #1 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #17 from Gary Funck 2012-08-12 18:11:25 UTC --- Created attachment 27996 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27996 test case #2 - struct targeted to TImode
[Bug libstdc++/51452] [DR 2116] has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|SUSPENDED Summary|has_nothrow_.*constructor |[DR 2116] |bugs|has_nothrow_.*constructor ||bugs --- Comment #14 from Jonathan Wakely 2012-08-12 18:14:43 UTC --- This is http://cplusplus.github.com/LWG/lwg-active.html#2116 so let's suspend this.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #18 from Gary Funck 2012-08-12 18:17:19 UTC --- Created attachment 27997 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27997 test case #3 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #19 from Gary Funck 2012-08-12 18:30:25 UTC --- (In reply to comment #15) > Do we have a run-time testcase? I attached three compile-time test cases that check if the generated RTL refers to TImode values. The test cases are set up to only run on x86_64 and x86 targets. I confirmed that they work as expected on an x86_64 target (with and without the MAX_FIXED_MODE_SIZE patch). Not sure if it will work on x86 or not. The test case may have to be tweaked for x86. Is this sufficient? I don't know how a run-time test would demonstrate the use of TImode, except in the form of a benchmark.
[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358 --- Comment #4 from Jan Kratochvil 2012-08-12 18:37:26 UTC --- It would not be helpful, systemtap would then see no data (just not wrong data). Also at that time location list will need to be used and currently GDB when it sees any location list it thinks it no longer needs to skip the prologue. OTOH GDB could look at -grecord-gcc-switches first which it currently does not so I should just finally implement -grecord-gcc-switches in GDB in such case.
[Bug c++/54235] New: Templates compile but don't link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54235
Bug #: 54235
Summary: Templates compile but don't link
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: todor.mi...@gmail.com
//This compiles but does not link on gcc 4.6.3, ubuntu 32 bit.
//Discussed at: http://www.cplusplus.com/forum/general/77046/#msg414427
//Compiles and links on other compilers/platforms.
//The code is a minified version from a real project.
//main.cpp
class Integer
{
public:
static unsigned int HashFunction(const Integer& input)
{ return 0;
}
};
template
class List
{
public:
inline unsigned int GetHash(const Object& input)const
{ return hashFunction(input);
}
};
template
class ListSpecialized: public List
{
};
template
class Element
{
public:
static inline unsigned int HashFunction(const Element& input)
{ CoefficientType x;
return inputHashFunction(x);
}
};
template
class TheComputation
{
public:
List, Element::HashFunction >
//ListSpecialized >
theList;
};
int main()
{ TheComputation A;
Element x;
A.theList.GetHash(x);
return 0;
}
[Bug libstdc++/52681] [C++11] Using std::thread without -pthread crashes without warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52681 --- Comment #7 from Jonathan Wakely 2012-08-12 18:57:58 UTC --- Author: redi Date: Sun Aug 12 18:57:53 2012 New Revision: 190330 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190330 Log: PR libstdc++/52681 * src/c++11/thread.cc (thread::_M_start_thread): Improve error text when threads are not enabled. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/thread.cc
[Bug libstdc++/52681] [C++11] Using std::thread without -pthread crashes without warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52681 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #8 from Jonathan Wakely 2012-08-12 19:02:45 UTC --- fixed for 4.8
[Bug fortran/54234] -Wconversion or -Wconversion-extra should warn for CMPLX(dp,dp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54234
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3 from Tobias Burnus 2012-08-12
19:21:41 UTC ---
(In reply to comment #1)
> The Fortran standard explicitly states that CMPLX returns
> a complex number with default real kind if the KIND= optional
> argument is not used.
Well, if it weren't valid, gfortran shouldn't warn but print an error. I
recently only found a bug in our program because of a warning about assigning
an REAL to an INTEGER, which should have been a REAL – thus, such warnings can
be helpful.
(In reply to comment #2)
> This is certainly a mistake made by lots of people,
> so I think a warning would be appropriate.
That's also the reason for suggesting this. The question is whether
-Wconversion (which is enabled by -Wall) or -Wconversion-extra (which is hidden
in the manual) is the better choice. It seems to be a somewhat common problem.
The case that one wants to have the default kind but uses a higher-precision
argument, seems to be rather rare; hence, I am inclined to warn already with
-Wconversion/-Wall.
(Side note: REAL always confuses me – for a complex number it returns the kind
of the argument - but for integer/real the default-kind.)
Untested patch – for -Wconversion-extra
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1278,6 +1278,17 @@ gfc_check_cmplx (gfc_expr *x, gfc_expr *y, gfc_expr
*kind)
if (kind_check (kind, 2, BT_COMPLEX) == FAILURE)
return FAILURE;
+ if (y && !kind && gfc_option.warn_conversion_extra
+ && x->ts.type == BT_REAL && x->ts.kind > gfc_default_real_kind)
+gfc_warning_now ("Conversion from %s to default-kind COMPLEX(%d) at %L "
+"might loose precision, consider using the KIND argument",
+gfc_typename (&x->ts), gfc_default_real_kind, &x->where);
+ else if (y && !kind && gfc_option.warn_conversion_extra
+ && y->ts.type == BT_REAL && y->ts.kind > gfc_default_real_kind)
+gfc_warning_now ("Conversion from %s to default-kind COMPLEX(%d) at %L "
+"might loose precision, consider using the KIND argument",
+gfc_typename (&y->ts), gfc_default_real_kind, &y->where);
+
return SUCCESS;
}
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #20 from H.J. Lu 2012-08-12 19:50:08 UTC --- (In reply to comment #19) > (In reply to comment #15) > > Do we have a run-time testcase? > > I attached three compile-time test cases that check if the generated RTL > refers > to TImode values. The test cases are set up to only run on x86_64 and x86 > targets. I confirmed that they work as expected on an x86_64 target (with and > without the MAX_FIXED_MODE_SIZE patch). Not sure if it will work on x86 or > not. The test case may have to be tweaked for x86. X86 doesn't support __int128 and requires SSE for TImode. We may need to limit those testcases for int128 target. > Is this sufficient? I don't know how a run-time test would demonstrate the > use > of TImode, except in the form of a benchmark. If it is an ABI, we can add a testcase to gcc.target/x86_64/abi for x86-64. If there is no additional issues for x86-64, I think we can close it after checking in those testcases.
[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358 --- Comment #5 from Frank Ch. Eigler 2012-08-12 20:21:24 UTC --- (In reply to comment #4) > It would not be helpful, systemtap would then see no data [...] Not quite; systemtap can search the PC ranges/line tables for a nearby address where a corrected location list would cover.
[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358 --- Comment #6 from Mark Wielaard 2012-08-12 20:30:36 UTC --- (In reply to comment #5) > (In reply to comment #4) > > It would not be helpful, systemtap would then see no data [...] > > Not quite; systemtap can search the PC ranges/line tables for a nearby address > where a corrected location list would cover. And at least systemtap could give an error/warning to the user the data isn't available instead of providing bogus values...
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #11 from Larry Baker 2012-08-12 21:24:31
UTC ---
Andreas,
I have patched the Code Sourcery gcc 4.6.1+ ColdFire cross-compiler to fix the
bugs I found for "-m68020 -fPIC -fstack-limit-symbol" and to implement
-fstack-limit-symbol for non-68020 processors.
The correct code is now generated for -mcpu=68020 -fPIC
-fstack-limit-symbol=__stack_start. The PIC offset table register, A5, is now
loaded before it is referenced by the stack check code:
Larrys-MacBook-Air:gcc baker$
/usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=68020 -fPIC
-fstack-limit-symbol=__stack_start -o junk.s junk.c
junk
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Assembling functions:
junk
Execution times (seconds)
tree gimplify : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (25%) wall
0 kB ( 0%) ggc
unaccounted todo : 0.00 ( 0%) usr 0.01 (100%) sys 0.01 (25%) wall
0 kB ( 0%) ggc
TOTAL : 0.00 0.01 0.04
1090 kB
Larrys-MacBook-Air:gcc baker$ cat junk.s
#NO_APP
.file"junk.c"
.text
.align2
.globljunk
.typejunk, @function
junk:
link.w %fp,#0
lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5
move.l __stack_start@GOT(%a5),%d0
addq.l #4,%d0
cmp.l %sp,%d0
traphi
unlk %fp
rts
.sizejunk, .-junk
.ident"GCC: (GNU) 4.6.1"
.section.note.GNU-stack,"",@progbits
This required patches to m68k.c and m68k.md. I also moved the calculation of
current_function_static_stack_size and limit to account for the stack size
increase on ColdFire processors (use fsize_with_regs in place of
current_frame.size).
RTL is now defined to generate code for -fstack-limit-symbol for non-68020
processors:
Larrys-MacBook-Air:gcc baker$
/usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=5208 -fPIC
-fstack-limit-symbol=__stack_start -o junk.s junk.c
junk
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Assembling functions:
junk
Execution times (seconds)
unaccounted todo : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (100%) wall
0 kB ( 0%) ggc
TOTAL : 0.00 0.00 0.01
1089 kB
Larrys-MacBook-Air:gcc baker$ cat junk.s#NO_APP
.file"junk.c"
.text
.align2
.globljunk
.typejunk, @function
junk:
link.w %fp,#0
move.l #_GLOBAL_OFFSET_TABLE_@GOTPC, %a5
lea (-6, %pc, %a5), %a5
move.l __stack_start@GOT(%a5),%d0
addq.l #4,%d0
cmp.l %sp,%d0
bls .+2
trap #7
unlk %fp
rts
.sizejunk, .-junk
.ident"GCC: (GNU) 4.6.1"
.section.note.GNU-stack,"",@progbits
This required patches to m68k.md. I implemented the "*conditional_trap"
pattern for non-68020 processors and renamed "*conditional_trap" to
"*conditional_trap_68020" for 68020 processors.
Compilation, linking, and conversion to uClinux Flat Binary format now works
for ColdFire processors (but does not for 32-bit 68020, which is okay):
Larrys-MacBook-Air:gcc baker$ /usr/local/gcc-4.6-2011.09/bin/m68k-uclinux-gcc
-mcpu=68020 -fPIC -fstack-limit-symbol=__stack_start -o junk main.c junk.c
/usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: reloc type
R_68K_GOT32O is not supported
/usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: reloc type
R_68K_GOT32O is not supported
/usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: 2 bad relocs
collect2: ld returned 1 exit status
Larrys-MacBook-Air:gcc baker$ /usr/local/gcc-4.6-2011.09/bin/m68k-uclinux-gcc
-mcpu=5206 -fPIC -fstack-limit-symbol=__stack_start -o junk main.c junk.c
Please review my patches, m68k.{c,md}.trunk.patch. (I have to figure out how
to attach them.) I do not understand, for example, how the "TARGET_68020" in
define_expand "ctrapsi4" works. It seems not to be a problem to get to the
patterns for generating the correct conditional trap code for non-68020
processors. (Does that mean they are not necessary?) I have not tested real
code yet using the patched Code Sourcery gcc 4.6.1+ ColdFire cross-compiler. I
am on vacation at the moment. I will get back to that next week.
Larry Baker
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #21 from Gary Funck 2012-08-12 21:24:40
UTC ---
(In reply to comment #20)
> X86 doesn't support __int128 and requires SSE for TImode.
> We may need to limit those testcases for int128 target.
OK, I'll add: /* { dg-require-effective-target int128 } */.
> If it is an ABI, we can add a testcase to gcc.target/x86_64/abi
> for x86-64. If there is no additional issues for x86-64, I think
> we can close it after checking in those testcases.
This issue is performance-related, not ABI-related, per the discussion replies.
The tests will FAIL on the current compiler because it does not assign TI mode
to 128 bit struct's. The tests PASS if the suggested MAX_FIXED_MODE_SIZE
definition is added to config/i386/i386.h.
Note: Applying the new MAX_FIXED_MODE_SIZE definition patch will result in at
least one GCC test regression (see comment #9).
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #12 from Larry Baker 2012-08-12 21:28:39 UTC --- Created attachment 27998 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27998 Patch for trunk version 2012-08-12 of gcc/config/m68k.m68k.c
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #13 from Larry Baker 2012-08-12 21:29:58 UTC --- Created attachment 27999 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27999 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 Gary Funck changed: What|Removed |Added Attachment #27995|0 |1 is obsolete|| --- Comment #22 from Gary Funck 2012-08-12 21:45:09 UTC --- Created attachment 28000 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28000 test case #1 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 Gary Funck changed: What|Removed |Added Attachment #27996|0 |1 is obsolete|| --- Comment #23 from Gary Funck 2012-08-12 21:47:47 UTC --- Created attachment 28001 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28001 test case #2 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 Gary Funck changed: What|Removed |Added Attachment #27997|0 |1 is obsolete|| --- Comment #24 from Gary Funck 2012-08-12 21:50:33 UTC --- Created attachment 28002 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28002 test case #3 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #25 from Gary Funck 2012-08-12 22:08:50 UTC --- (In reply to comment #20) > X86 doesn't support __int128 and requires SSE for TImode. > We may need to limit those testcases for int128 target. If targeting struct's to TImode is supported on x86 targets then perhaps this definition will need to be refer to 128 bit target support? #define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode) Off-hand, I don't know the target macro that does this. something like this? #define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode : DImoe
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #26 from Gary Funck 2012-08-12 22:14:56 UTC --- Typo fixed below: #define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode : DImode
[Bug target/54236] New: [SH] Improve addc and subc insn utilization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236
Bug #: 54236
Summary: [SH] Improve addc and subc insn utilization
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: olege...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
There are currently a couple of cases, where it would be better if addc or subc
insns were used. For example:
int test00 (int a, int b)
{
return a + b + 1;
}
gets compiled to:
mov r4,r0 ! MT
add r5,r0 ! EX
rts
add #1,r0 ! EX
could be better as:
mov r4,r0 ! MT
settr5,r0 ! MT (SH4)
rts
addc#1,r0 ! EX
As a proof of concept, I've applied the following to handle the above case:
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md(revision 190326)
+++ gcc/config/sh/sh.md(working copy)
@@ -1465,7 +1465,7 @@
(define_insn "addc"
[(set (match_operand:SI 0 "arith_reg_dest" "=r")
-(plus:SI (plus:SI (match_operand:SI 1 "arith_reg_operand" "0")
+(plus:SI (plus:SI (match_operand:SI 1 "arith_reg_operand" "%0")
(match_operand:SI 2 "arith_reg_operand" "r"))
(reg:SI T_REG)))
(set (reg:SI T_REG)
@@ -1516,6 +1516,24 @@
"add%2,%0"
[(set_attr "type" "arith")])
+(define_insn_and_split "*addsi3_compact"
+ [(set (match_operand:SI 0 "arith_reg_dest" "")
+(plus:SI (plus:SI (match_operand:SI 1 "arith_reg_operand" "")
+ (match_operand:SI 2 "arith_reg_operand" ""))
+ (const_int 1)))
+ (clobber (reg:SI T_REG))]
+ "TARGET_SH1"
+ "#"
+ "&& 1"
+ [(set (reg:SI T_REG) (const_int 1))
+ (parallel [(set (match_dup 0)
+ (plus:SI (plus:SI (match_dup 1)
+ (match_dup 2))
+(reg:SI T_REG)))
+ (set (reg:SI T_REG)
+ (ltu:SI (plus:SI (match_dup 1) (match_dup 2))
+ (match_dup 1)))])])
+
;; -
;; Subtraction instructions
;; -
.. and observed some code from the CSiBE set for -O2 -m4-single -ml
-mpretend-cmove. It doesn't affect code size that much (some incs/decs here
and there), but more importantly it does this (libmpeg2/motion_comp.c):
_MC_avg_o_16_c:-->
mov.b @r5,r1mov.b@r5,r2
.L16:.L16:
mov.b @r4,r2 sett
extu.b r1,r1 mov.b@r4,r1
extu.b r2,r2 extu.br2,r2
add r2,r1 extu.br1,r1
add #1,r1 addcr2,r1
sharr1 sharr1
mov.b r1,@r4 mov.br1,@r4
mov.b @(1,r5),r0 sett
extu.b r0,r1 mov.b@(1,r5),r0
mov.b @(1,r4),r0 extu.br0,r1
extu.b r0,r0 mov.b@(1,r4),r0
add r0,r1 extu.br0,r0
add #1,r1 addcr1,r0
sharr1 sharr0
mov r1,r0 mov.br0,@(1,r4)
mov.b r0,@(1,r4)
In such cases, the sett,addc sequence can be scheduled much better and in most
cases the sett insn can be executed in parallel with some other insn.
Unfortunately, on SH4A the sett insn has been moved from MT group to EX group,
but still it seems beneficial. I've also seen a couple of places, where
sett-subc sequences would be better.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
H.J. Lu changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #27 from H.J. Lu 2012-08-12 22:30:32
UTC ---
(In reply to comment #25)
> (In reply to comment #20)
> > X86 doesn't support __int128 and requires SSE for TImode.
> > We may need to limit those testcases for int128 target.
>
> If targeting struct's to TImode is supported on x86 targets then perhaps this
> definition will need to be refer to 128 bit target support?
>
> #define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
>
> Off-hand, I don't know the target macro that does this.
There are:
rs6000/rs6000.h:#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_POWERPC64
? TImode : DImode)
s390/s390.h:#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode
: DImode)
Please try this patch:
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index c4d85b7..6c4c2ce 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1853,6 +1853,10 @@ do {\
/* #define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) 0 */
+/* An integer expression for the size in bits of the largest integer machine
+ mode that should actually be used. We allow pairs of registers. */
+#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
+
/* Define this macro if it is as good or better to call a constant
function address than to call an address kept in a register.
[Bug target/54236] [SH] Improve addc and subc insn utilization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-08-12 Ever Confirmed|0 |1
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #28 from Gary Funck 2012-08-12 22:43:16
UTC ---
(In reply to comment #27)
> Please try this patch:
>
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index c4d85b7..6c4c2ce 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -1853,6 +1853,10 @@ do {\
>
> /* #define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) 0 */
>
> +/* An integer expression for the size in bits of the largest integer machine
> + mode that should actually be used. We allow pairs of registers. */
> +#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
> +
> /* Define this macro if it is as good or better to call a constant
> function address than to call an address kept in a register.
That's the patch that I have been using and testing against (ref: comment #9).
I suggested this:
#define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode :
DImode
because it might allow x86 targets with SSE to also target TIMode for 128 bit
struct's (on the assumption that TImode will be more efficient).
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #47 from Oleg Endo 2012-08-12 22:47:21 UTC --- Author: olegendo Date: Sun Aug 12 22:47:15 2012 New Revision: 190331 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190331 Log: PR target/51244 * config/sh/sh.md: Add splits for inverted compare and branch opportunities. (*cmpeqsi_t): New insn. (cmpgtsi_t, cmpgesi_t): Swap r and N alternatives. (cmpgeusi_t): Use satisfies_constraint_Z. Emit sett insn in replacement insn list and not in the preparation statements. (clrt, sett): Add mt_group attribute. PR target/51244 * gcc.target/sh/pr51244-7.c: New. * gcc.target/sh/pr51244-8.c: New. * gcc.target/sh/pr51244-9.c: New. * gcc.target/sh/pr51244-10.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr51244-10.c trunk/gcc/testsuite/gcc.target/sh/pr51244-7.c trunk/gcc/testsuite/gcc.target/sh/pr51244-8.c trunk/gcc/testsuite/gcc.target/sh/pr51244-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug c++/54198] [4.8 Regression] "error: invalid use of incomplete type" when building Chromium
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54198 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Daniel Krügler 2012-08-12 22:58:09 UTC --- (In reply to comment #2) > I actually think GCC is correct, A causes all member functions to be > instantiated. I disagree, the instantiation of A shall only instantiate all member *declarations*, but not the *definitions* of unused members.
[Bug c++/54235] Templates compile but don't link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54235 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-08-12 23:25:51 UTC --- The problem still exists in gcc 4.8 trunk
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #29 from H.J. Lu 2012-08-13 02:17:28
UTC ---
(In reply to comment #28)
> (In reply to comment #27)
> > Please try this patch:
> >
> > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> > index c4d85b7..6c4c2ce 100644
> > --- a/gcc/config/i386/i386.h
> > +++ b/gcc/config/i386/i386.h
> > @@ -1853,6 +1853,10 @@ do {\
> >
> > /* #define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) 0 */
> >
> > +/* An integer expression for the size in bits of the largest integer
> > machine
> > + mode that should actually be used. We allow pairs of registers. */
> > +#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode :
> > DImode)
> > +
> > /* Define this macro if it is as good or better to call a constant
> > function address than to call an address kept in a register.
>
> That's the patch that I have been using and testing against (ref: comment #9).
>
> I suggested this:
> #define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode
> :
> DImode
> because it might allow x86 targets with SSE to also target TIMode for 128 bit
> struct's (on the assumption that TImode will be more efficient).
ix86_scalar_mode_supported_p (TImode) returns false for -m32
even when SSE is enabled. You can submit a patch with
#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
plus some testcases.
[Bug libstdc++/54237] New: [C++11] Make more tuple-related functions constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54237 Bug #: 54237 Summary: [C++11] Make more tuple-related functions constexpr Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com Many tuple-related functions are already constexpr (e.g. tuple constructors, get(), tuple_cat(), make_tuple()). I think more of them can be made constexpr, in particular tie() and the comparison operators (operator< and friends).
[Bug fortran/54238] New: If possible, TRANSFER should use assignment instead of MEMCPY
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54238
Bug #: 54238
Summary: If possible, TRANSFER should use assignment instead of
MEMCPY
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
In some cases TRANSFER can be replaced by a normal assignment (with cast),
possibly also a ARRAY_RANGE_REF with cast?
Example, the following code – which matches the currently used scalarizer for
FINAL:
use iso_c_binding, only: c_intptr_t, c_loc, c_ptr, c_int, c_f_pointer
integer(c_int), target :: array(4)
integer(c_int), pointer :: ptr
integer(c_intptr_t) :: addr
type(c_ptr) :: cptr
array = [11,22,33,44]
do i = 0, 3
cptr = c_loc (array)
addr = transfer (cptr, addr) + i * storage_size (array)/8
call c_f_pointer (transfer (addr, cptr), ptr)
print *, i,': ', ptr
end do
end
Dump of: addr = transfer (cptr, addr) + i * storage_size (array)/8
{
struct array1_integer(kind=4) parm.2;
integer(kind=8) transfer.1;
integer(kind=8) D.1876;
integer(kind=8) D.1875;
integer(kind=8) D.1874;
D.1874 = 8;
D.1875 = 8;
__builtin_memcpy ((void *) &transfer.1, (void *) &cptr,
MAX_EXPR , 0>);
parm.2.dtype = 265;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 4;
parm.2.dim[0].stride = 1;
parm.2.data = (void *) &array[0];
parm.2.offset = -1;
addr = (integer(kind=8)) ((i * 32) / 8) + transfer.1;
}
While a simple
addr = (intptr_t) cptr;
should be sufficient.
[Bug fortran/54238] If possible, TRANSFER should use assignment instead of MEMCPY
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54238 --- Comment #1 from Andrew Pinski 2012-08-13 06:15:43 UTC --- Though the memcpy does get optimized to a VCE: addr.9_4 = (integer(kind=8)) ivtmp.29_28; D.1913_24 = VIEW_CONVERT_EXPR(addr.9_4); So it might not be important enough to do at the front-end level.
[Bug bootstrap/50167] gmp memory functions are extern "C" (graphite)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50167 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #2 from Marc Glisse 2012-08-13 06:17:30 UTC --- Note that this could also be solved by using gmp_fprintf. (Or by using mpz_class::get_str, since we seem to be moving to C++ anyway)
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-13 CC||aldyh at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever Confirmed|0 |1
