[Bug c/60114] Incorrect column number for -pedantic and -Wconversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60114 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-02-08 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Mine.
[Bug c++/60113] Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60113 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-08 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/60114] Incorrect column number for -pedantic and -Wconversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60114 --- Comment #2 from Chengnian Sun chengniansun at gmail dot com --- It seems -pedantic and -Woverflow are different. When I issue $ gcc-trunk -c -Woverflow s.c then there is no overflow warning. (There is indeed no overflow.) But when I use $ gcc-trunk -c -pedantic s.c the warning says that it is emitted from -Woverflow. Is this expected?
[Bug c++/19377] Using declaration in private part causes protected diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377
Harald van Dijk harald at gigawatt dot nl changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #12 from Harald van Dijk harald at gigawatt dot nl ---
Fabien, are you sure that the test case in comment 9 is invalid? C++11 reads
In a using-declaration used as a member-declaration, the nested-name-specifier
shall name a base class of the class being defined. If such a using-declaration
names a constructor, the nested-name-specifier shall name a direct base class
of the class being defined; otherwise it introduces the set of declarations
found by member name lookup (10.2, 3.4.3.1).
which makes sense: any inherited member, even from an indirect base class, can
be introduced into the current class, except for an indirect base class's
constructor.
As for It is invalid for a second reason, 'using Base::i' is declared
(implicitly) in a private section, so inaccessible in DerivedDerived., the
DerivedDerived using declaration uses a fully qualified ns::Base::i, the
visibility of which should depend on the visibility in Base, not the visibility
in Derived. If the code used ns::Derived::i, then it would make sense to issue
an error, and clang does emit an error in that case.
As for being separate from this bug, a trivial change of that test case to
namespace ns {
class Base {
protected:
int i;
};
class Derived : public Base {
using Base::i;
};
}
class DerivedDerived : public ns::Derived {
using ns::Base::i;
};
makes GCC emit
test.cc:4:9: error: ‘int ns::Base::i’ is protected
int i;
^
test.cc:11:7: error: within this context
class DerivedDerived : public ns::Derived {
^
which is exactly the error message that this bug is about. Similarly, changing
the protected: to public: in the original test case changes the error
message from protected to inaccessible.
[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Target||i386-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-08 Component|tree-optimization |rtl-optimization Target Milestone|--- |4.9.0 Summary|wrong code at -Os on|[4.8/4.9 Regression] wrong |x86_64-linux-gnu in 32-bit |code at -Os on |mode|x86_64-linux-gnu in 32-bit ||mode Ever confirmed|0 |1 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- .optimized dump looks ok to me, so either RTL or target.
[Bug c/60114] Incorrect column number for -pedantic and -Wconversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60114 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- -Woverflow is turned on by default, so it doesn't matter if you specify it or not; what matters here is the -Wpedantic (we have a bug about that discrepancy: PR59753). So yeah, expected.
[Bug c++/60097] spurious warning about command line option -Wno-mismatched-tags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60097
Harald van Dijk harald at gigawatt dot nl changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #1 from Harald van Dijk harald at gigawatt dot nl ---
This is intentional. Messages for unrecognised -Wno-* options are only emitted
if there are warnings.
If there are no warnings, there are no warnings to be suppressed either, so
ignoring the option cannot do any harm. This allows code intended to build
warning-free to unconditionally add -Wno-* options made available in e.g. GCC
4.9 even when GCC 4.8 is used as the compiler.
If there are warnings, a diagnostic for the -Wno-* option is more useful, as it
could point to a typo in the command-line option intended to suppress one of
the current warnings, for example:
$ cat test.c
int main() { }
$ gcc -Wall -Wno-retrun-type -c test.c
test.c: In function ‘main’:
test.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
int main() { }
^
test.c: At top level:
cc1: warning: unrecognized command line option -Wno-retrun-type [enabled by
default]
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Sat Feb 8 09:09:01 2014 New Revision: 207628 URL: http://gcc.gnu.org/viewcvs?rev=207628root=gccview=rev Log: PR middle-end/60092 * tree-ssa-ccp.c (surely_varying_stmt_p): Don't return true if TYPE_ATTRIBUTES (gimple_call_fntype ()) contain assume_aligned or alloc_align attributes. (bit_value_assume_aligned): Add ATTR, PTRVAL and ALLOC_ALIGN arguments. Handle also assume_aligned and alloc_align attributes. (evaluate_stmt): Adjust bit_value_assume_aligned caller. Handle calls to functions with assume_aligned or alloc_align attributes. * doc/extend.texi: Document assume_aligned and alloc_align attributes. c-family/ * c-common.c (handle_alloc_size_attribute): Use tree_fits_uhwi_p and tree_to_uhwi. (handle_alloc_align_attribute, handle_assume_aligned_attribute): New functions. (c_common_attribute_table): Add alloc_align and assume_aligned attributes. testsuite/ * gcc.dg/attr-alloc_align-1.c: New test. * gcc.dg/attr-alloc_align-2.c: New test. * gcc.dg/attr-alloc_align-3.c: New test. * gcc.dg/attr-assume_aligned-1.c: New test. * gcc.dg/attr-assume_aligned-2.c: New test. * gcc.dg/attr-assume_aligned-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/attr-alloc_align-1.c trunk/gcc/testsuite/gcc.dg/attr-alloc_align-2.c trunk/gcc/testsuite/gcc.dg/attr-alloc_align-3.c trunk/gcc/testsuite/gcc.dg/attr-assume_aligned-1.c trunk/gcc/testsuite/gcc.dg/attr-assume_aligned-2.c trunk/gcc/testsuite/gcc.dg/attr-assume_aligned-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59984 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Sat Feb 8 09:10:14 2014 New Revision: 207629 URL: http://gcc.gnu.org/viewcvs?rev=207629root=gccview=rev Log: PR c/59984 * gimplify.c (gimplify_bind_expr): In ORT_SIMD region mark local addressable non-static vars as GOVD_PRIVATE instead of GOVD_LOCAL. * omp-low.c (lower_omp_for): Move gimple_bind_vars and BLOCK_VARS of gimple_bind_block to new_stmt rather than copying them. * gcc.dg/vect/pr59984.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr59984.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org, ||uros at gcc dot gnu.org Component|rtl-optimization|target --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, it's target. Started with r184891.
[Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59984 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- The wrong-code issue is now fixed, but we still don't vectorize this. See http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00514.html for details. Note that without making the two pointer parameters linear on the elemental function it actually will not be successfully vectorized unless you have CPU that can do scatter (Skylake, anything else?). Keeping this PR open so that I don't forget to address this.
[Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59984 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug translation/52289] translatable string typo: must not be have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52289 --- Comment #3 from Andreas Schwab schwab at gcc dot gnu.org --- Author: schwab Date: Sat Feb 8 09:33:24 2014 New Revision: 207630 URL: http://gcc.gnu.org/viewcvs?rev=207630root=gccview=rev Log: PR translation/52289 * gfortran.dg/coarray_8.f90: Update dg-error match. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_8.f90
[Bug tree-optimization/60115] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-02-08
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.9.0
Summary|wrong code at -O3 on|[4.9 Regression] wrong code
|x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
I have to use something like:
int a, b[1];
int
main ()
{
lbl:
for (; a; a--)
if (b[1000])
goto lbl;
return 0;
}
to actually successfully reproduce it. Anyway, started with r204458.
[Bug target/59927] [4.9 Regression] ICE sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59927 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Richard Henderson from comment #6) I'll attempt to test this at some point this weekend, but I'm not currently in a position to build on x86_64 windows. Kai, can you fire something off? I will do a build over weekend for it. One side-note I have about this patch. Due this allow drap-register for x64, we seem to need to enable eax_live for this target, too. See in ix86_expand_prologue the lines ... if (!TARGET_64BIT_MS_ABI) eax_live = ix86_eax_live_at_start_p (); ...
[Bug tree-optimization/58556] [4.9 Regression] gen-vect-26.c / gen-vect-28.c regression merging from r202839 to r202981
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58556
--- Comment #7 from clyon at gcc dot gnu.org ---
Author: clyon
Date: Sat Feb 8 12:14:11 2014
New Revision: 207631
URL: http://gcc.gnu.org/viewcvs?rev=207631root=gccview=rev
Log:
2014-02-01 Christophe Lyon christophe.l...@linaro.org
Backport from trunk r202875,202980.
2013-09-24 Xinliang David Li davi...@google.com
* tree-vect-data-refs.c (vect_enhance_data_refs_alignment):
Check max peel iterations parameter.
* param.def: New parameter.
* doc/invoke.texi: Document New parameter.
2013-09-27 Xinliang David Li davi...@google.com
* opts.c (finish_options): Adjust parameters
according to vect cost model.
(common_handle_option): Set dynamic vect cost
model for FDO.
targhooks.c (default_add_stmt_cost): Compute stmt cost
unconditionally.
* tree-vect-loop.c (vect_estimate_min_profitable_iters):
Use helper function.
* tree-vectorizer.h (unlimited_cost_model): New function.
* tree-vect-slp.c (vect_slp_analyze_bb_1): Use helper function.
* tree-vect-data-refs.c (vect_peeling_hash_insert): Use helper
function.
(vect_enhance_data_refs_alignment): Ditto.
* flag-types.h: New enum.
* common/config/i386/i386-common.c (ix86_option_init_struct):
No need to initialize vect_cost_model flag.
* config/i386/i386.c (ix86_add_stmt_cost): Compute stmt cost
unconditionally.
2014-02-01 Christophe Lyon christophe.l...@linaro.org
Backport from trunk r203057.
2013-10-01 Kyrylo Tkachov kyrylo.tkac...@arm.com
PR tree-optimization/58556
* gcc.dg/tree-ssa/gen-vect-26.c: Use dynamic vector cost model.
* gcc.dg/tree-ssa/gen-vect-28.c: Likewise.
Modified:
branches/linaro/gcc-4_8-branch/ (props changed)
branches/linaro/gcc-4_8-branch/gcc/ChangeLog.linaro
branches/linaro/gcc-4_8-branch/gcc/common.opt
branches/linaro/gcc-4_8-branch/gcc/common/config/i386/i386-common.c
branches/linaro/gcc-4_8-branch/gcc/config/i386/i386.c
branches/linaro/gcc-4_8-branch/gcc/doc/invoke.texi
branches/linaro/gcc-4_8-branch/gcc/flag-types.h
branches/linaro/gcc-4_8-branch/gcc/opts.c
branches/linaro/gcc-4_8-branch/gcc/params.def
branches/linaro/gcc-4_8-branch/gcc/targhooks.c
branches/linaro/gcc-4_8-branch/gcc/testsuite/ChangeLog.linaro
branches/linaro/gcc-4_8-branch/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c
branches/linaro/gcc-4_8-branch/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c
branches/linaro/gcc-4_8-branch/gcc/tree-vect-data-refs.c
branches/linaro/gcc-4_8-branch/gcc/tree-vect-loop.c
branches/linaro/gcc-4_8-branch/gcc/tree-vect-slp.c
branches/linaro/gcc-4_8-branch/gcc/tree-vectorizer.h
Propchange: branches/linaro/gcc-4_8-branch/
('svn:mergeinfo' modified)
[Bug fortran/60091] Misleading error messages in rank-2 pointer assignment to rank-1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60091 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed and I agree that three attempts to get the correct syntax could be frustrating.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #101 from Paul Thomas pault at gcc dot gnu.org --- (In reply to Richard Biener from comment #100) Fixed on trunk. Hi Richard, Do you intend to backport this to 4.8 or, come to that, is it even backportable? If 'no' to either, I'll close it out (I am engaged in regression bashing this afternoon). Cheers Paul PS Thanks to everybody for their intestinal fortitude and persistence in fixing this PR!
[Bug c++/60112] bogus error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60112 --- Comment #2 from David Abdurachmanov david.abdurachmanov at gmail dot com --- Tested today on r207627, still the same result. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/build1/davidlt/ngcc490/a/slc6_amd64_gcc490/external/gcc/4.9.0-cms/bin/../libexec/gcc/x86_64-redhat-linux-gnu/4.9.0/lto-wrapper Target: x86_64-redhat-linux-gnu Configured with: ../configure --prefix=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms --disable-multilib --disable-nls --with-system-zlib --disable-dssi --enable-languages=c,c++,fortran --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-plugin --w ith-linker-hash-style=gnu --enable-linker-build-id --enable-gold=yes --enable-ld=default --enable-lto --with-gmp=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f 4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms --with-mpfr=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc /4.9.0-cms --with-mpc=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms --with-isl=/build1/davidlt/ngcc490/ a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms --with-cloog=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f 4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms --enable-checking=release --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --enable-libstdcxx-time=rt --enable- shared CC='gcc -fPIC' CXX='c++ -fPIC' CPP=cpp CXXCPP='c++ -E' CFLAGS=-I/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/ gcc/4.9.0-cms/tmp/sw/include CXXFLAGS=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/tmp/sw/include LDFL AGS=-L/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/tmp/sw/lib Thread model: posix gcc version 4.9.0 (GCC)
[Bug fortran/59612] [F03] iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- Should not this PR be closed as FIXED?
[Bug c++/60097] spurious warning about command line option -Wno-mismatched-tags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60097 dan at math dot uiuc.edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from dan at math dot uiuc.edu --- Ingenious! Thank you.
[Bug fortran/58000] Accept OPEN( ... NAME=) with -std=legacy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58000
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2014-02-08
Ever confirmed|0 |1
--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I don't see the need for this extension: replacing NAME= (name=) with
FILE= (file=) is trivial with sed or other editing tools if the code does
not contain any variable 'NAME' ('name'). If it does, the task remains
semi-trivial using regular expressions.
Unless someone objects I'll prepare another entry for the Extensions not
implemented in GNU Fortran section of the manual.
[Bug fortran/53077] replace Illegal preprocessor directive message with Ignoring preprocessor directive at %C. Use -cpp to enable the C preprocessor (a patch by Tobias included)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-08 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is there any objection if I do the testing and packaging for the patch in comment 4?
[Bug fortran/55916] Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 Jouko Orava jouko.orava at iki dot fi changed: What|Removed |Added CC||jouko.orava at iki dot fi --- Comment #8 from Jouko Orava jouko.orava at iki dot fi --- These issues affect probably all versions of gfortran, but I have verified this occurs with 4.6.4, 4.7.3, 4.8.1, and trunk revision 207606. It does seem unlikely that GNU libc malloc() will ever be modified to return sufficiently aligned pointers for vector types (or for long double on 32-bit ppc). I have a patch under testing against trunk that modifies libgfortran internal xmalloc() and xcalloc() calls, as well as the intrinsic malloc() calls, to use GNU libc specific memalign() call. I will attach it as soon as I verify it works correctly. If using memalign() is not acceptable, say so. The reason for using memalign() instead of posix_memalign() is that my (limited!) testing indicates that using memalign() has the least overhead. posix_memalign() has relatively larger overhead, possibly due to its call mechanism. aligned_alloc() is not a real possibility for now, because it was only added to glibc-2.16 (summer 2012). Computing clusters often have older libc versions, and requiring glibc-2.16 and newer would stop binaries compiled on newer gfortran versions from working. (And binaries are often compiled on newer compilers.) GCC generated code seems to assume malloc() returns a pointer aligned to at least __BIGGEST_ALIGNMENT__. Therefore marking the allocation functions with the malloc attribute (or perhaps with malloc and alloc_size) should be sufficient for GNU Fortran. (I shall also do some experiments with __builtin_assume_aligned() to see if there is any impact to the generated code, but I don't see any reason there should be. The compilation units are separate; AFAICT GCC must determine the pointer alignment from the pointer type only. That also matches current behaviour, and is the reason this bug exists.) Obviously, memalign() is obsolete, but I see the performance outweighing that here. After all, removing memalign() in a future glibc would be seen as petty, considering how tenderly emacs users have been treated; tolerating bugs for years, in order to not break existing emacs state dumps. My hardware selection is very limited, but if someone wishes to test the possibilities on other hardware, I'd be happy to clean up my benchmarking code.
[Bug fortran/55916] Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- My hardware selection is very limited, but if someone wishes to test the possibilities on other hardware, I'd be happy to clean up my benchmarking code. I can do the testing on darwin (intel d10 and d13, ppc d9).
[Bug c++/19377] Using declaration in private part causes protected diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- FWIW Harald's analysis looks right to me
[Bug c/60114] Incorrect column number for -pedantic and -Wconversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60114 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Chengnian Sun from comment #2) It seems -pedantic and -Woverflow are different. When I issue $ gcc-trunk -c -Woverflow s.c then there is no overflow warning. (There is indeed no overflow.) But when I use $ gcc-trunk -c -pedantic s.c the warning says that it is emitted from -Woverflow. Is this expected? There are some warnings that are only enabled if -Wpedantic is given in combination with other flag. Unfortunately, there is currently no way to say that a warning is enabled by the combination of two flags, short of creating a new flag -Wpedantic-overflow, which is enabled by the combination of -Wpedantic -Woverflow. I think it could be a nice workaround
[Bug tree-optimization/60115] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115
--- Comment #3 from Zhendong Su su at cs dot ucdavis.edu ---
(In reply to Jakub Jelinek from comment #2)
I have to use something like:
int a, b[1];
int
main ()
{
lbl:
for (; a; a--)
if (b[1000])
goto lbl;
return 0;
}
to actually successfully reproduce it. Anyway, started with r204458.
Thanks Jakub. That's interesting. It reproduces for me as small as 450 for the
array index.
[Bug tree-optimization/60115] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115
--- Comment #4 from Zhendong Su su at cs dot ucdavis.edu ---
(In reply to Jakub Jelinek from comment #2)
I have to use something like:
int a, b[1];
int
main ()
{
lbl:
for (; a; a--)
if (b[1000])
goto lbl;
return 0;
}
to actually successfully reproduce it. Anyway, started with r204458.
Should I report the out-out-bound array access warning issue as a separate
report? Thanks.
[Bug c/60117] New: simd reduction clause suppresses simd auto-vectorization when -fopenmp is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60117 Bug ID: 60117 Summary: simd reduction clause suppresses simd auto-vectorization when -fopenmp is set Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Created attachment 32082 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32082action=edit source code reproducer gcc version 4.9.0 20140203 gcc -O2 -ftree-vectorize -std=c99 -march=core-avx2 -fopt-info -S -fopenmp s314.c This uses vmaxss instruction in the main loop body, in spite of the fairly positive vectorization report. -O3 makes no significant difference, so -O2 is used in practice for stability elsewhere in gcc source code. If the omp simd is disabled by removing -fopenmp, excellent code is produced using vmaxps. Performance test shows 10x speedup with max-unroll-times=2.
[Bug c/60117] simd reduction clause suppresses simd auto-vectorization when -fopenmp is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60117 --- Comment #1 from tprince at computer dot org --- Created attachment 32083 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32083action=edit f2c style include file
[Bug c/60117] simd reduction clause suppresses simd auto-vectorization when -fopenmp is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60117 --- Comment #2 from tprince at computer dot org --- Jakub Jelinek requested this PR filing
[Bug c/60114] Incorrect column number for -pedantic and -Wconversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60114 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #4) (In reply to Chengnian Sun from comment #2) It seems -pedantic and -Woverflow are different. When I issue $ gcc-trunk -c -Woverflow s.c then there is no overflow warning. (There is indeed no overflow.) But when I use $ gcc-trunk -c -pedantic s.c the warning says that it is emitted from -Woverflow. Is this expected? There are some warnings that are only enabled if -Wpedantic is given in combination with other flag. Unfortunately, there is currently no way to say that a warning is enabled by the combination of two flags, short of creating a new flag -Wpedantic-overflow, which is enabled by the combination of -Wpedantic -Woverflow. I think it could be a nice workaround That said, I think it would be even nicer to print the flags that appear in the command-line (or pragmas) that triggered this warning, instead of the flag that controls it. So here it will print [-Wpedantic,-Woverflow]. Although we now record the relations between the flags explicitly in the *.opt files, there is no explicit structure that allows following the chain of dependencies.
[Bug fortran/60066] Bad elemental invocation of non-scalar base object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066 --- Comment #11 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Sat Feb 8 16:22:46 2014 New Revision: 207633 URL: http://gcc.gnu.org/viewcvs?rev=207633root=gccview=rev Log: 2014-02-08 Paul Thomas pa...@gcc.gnu.org PR fortran/60066 * gfortran.dg/elemental_subroutine_10.f90 : New test. This PR was fixed by the patch for PR59906. Added: trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_10.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #37 from Denis Kolesnik denis.v.koles...@safe-mail.net --- you are not right in the following: I did not visit sites where would be fair to contaminate my software with viruses and similar code and I do trust(not fully, but enough) to Microsoft support because of their reputation. And Microsoft claims to defend of such problems. Did I wrote here something wrong? Wait I will check now again after I did reinstall my system. I do not think, that I'm wrong here and that my guilt in this problems is most.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #38 from Denis Kolesnik denis.v.koles...@safe-mail.net --- if i find a bug I will reopen it and if I find intrusion in my software I will take actions accordingly.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Denis Kolesnik denis.v.koles...@safe-mail.net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #39 from Denis Kolesnik denis.v.koles...@safe-mail.net --- Dear Mr. Wakely, if people like you plan to make court of my money by some actions I better minimize my contacts with people like you, because after I did reinstall my system I have the same problem again. --
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #40 from Andreas Schwab sch...@linux-m68k.org --- spam.
[Bug fortran/60110] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1266
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60110
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC||janus at gcc dot gnu.org
Summary|internal compiler error |ICE in gfc_get_symbol_decl,
||at
||fortran/trans-decl.c:1266
--- Comment #6 from janus at gcc dot gnu.org ---
Further reduced test case:
implicit none
interface
function power (l, r)
character(*), intent(in) :: l, r
character(len(l)) :: power
end function
end interface
call check ( (/ power('a','b') /) )
contains
subroutine check (computed)
character(*), dimension(1), intent(in) :: computed
end subroutine
end
Same ICE (with everything from 4.4 to trunk at least).
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Denis Kolesnik denis.v.koles...@safe-mail.net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #41 from Denis Kolesnik denis.v.koles...@safe-mail.net --- spam? where do you see meat here?
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #42 from Denis Kolesnik denis.v.koles...@safe-mail.net --- do not even try to intrude my pc remotelly!
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #43 from Denis Kolesnik denis.v.koles...@safe-mail.net --- you guys yourself have bad culture if you tell me this is not the place to talk about my not working correctly compiler, but yourself talk about meat.
[Bug fortran/55916] Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 --- Comment #10 from Jouko Orava jouko.orava at iki dot fi --- (In reply to Dominique d'Humieres from comment #9) I can do the testing on darwin (intel d10 and d13, ppc d9). That would be very much appreciated. I've put a tarball and some background info on my web page at http://www.helsinki.fi/~joorava/memory/ Simply put, on my machine, 64-bit code has very little slowdown if memalign() (or even posix_memalign()) is used instead of malloc(). Compiling 32-bit code, both memalign() and posix_memalign() incur a 2x to 4x more CPU time, with posix_memalign() having a more or less fixed overhead compared to memalign(). As I mention on the web page, I only wrote this to have a reason to select a specific function. To me, the results indicate memalign() is the second-best choice (best being fixing malloc()). If you find any errors, or have results I may add to the above page (whether or not they contradict mine), I'd be happy to include your notes there.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #44 from Jonathan Wakely redi at gcc dot gnu.org --- Noone said to reinstall your computer. Noone here is trying to attack your computer. Your program is not correct, that's why it doesn't work. The problem is not with GCC. Now please go away.
[Bug fortran/60118] New: Internal compiler error gfc_trans_assignment_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60118 Bug ID: 60118 Summary: Internal compiler error gfc_trans_assignment_1 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fmartinez at gmv dot com Created attachment 32084 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32084action=edit Test source file The attached code produces an internal compiler error. m_util_convert.f90: In function ‘char_to_buffer’: m_util_convert.f90:26:0: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:8012 res = ichar( cpk, kind=1 ) ^ Same behaviour for version 4.7 and 4.8. Details in attached file.
[Bug fortran/60118] Internal compiler error gfc_trans_assignment_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60118 Fran Martinez Fadrique fmartinez at gmv dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Fran Martinez Fadrique fmartinez at gmv dot com --- This one has been submitted by mistake. It awas already reported although the new submission provides additional details on version 4.7 and 4.8 *** This bug has been marked as a duplicate of bug 59599 ***
[Bug fortran/59599] Compiler internal error on intrinsic ichar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59599 --- Comment #2 from Fran Martinez Fadrique fmartinez at gmv dot com --- *** Bug 60118 has been marked as a duplicate of this bug. ***
[Bug target/60111] [SH] ICE compiling Newlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60111 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- Interesting. Maybe PR 59375 is related somehow.
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
This patch avoids the self-move:
index 4c6ca8a..6ce2d21 100644
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -4430,7 +4430,12 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
if (__first != __last)
for (_RandomAccessIterator __i = __first + 1; __i != __last; ++__i)
- std::iter_swap(__i, __first + (std::rand() % ((__i - __first) + 1)));
+ {
+ int __offset = std::rand() % ((__i - __first) + 1);
+ _RandomAccessIterator __j = __first + __offset;
+ if (__i != __j)
+ std::iter_swap(__i, __j);
+ }
}
/**
But I'm not sure whether this is a real bug, or types used with random_shuffle
should be safe against self-move (which means they can't use an implicit move
ctor if they have types that are not safe against self-move, which includes
most std::lib types).
[Bug fortran/57033] [4.7/4.8/4.9 Regression] ICE on extended derived type and default initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57033 --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Sat Feb 8 20:37:55 2014 New Revision: 207634 URL: http://gcc.gnu.org/viewcvs?rev=207634root=gccview=rev Log: fortran/ PR fortran/57033 * primary.c (gfc_convert_to_structure_constructor): Avoid null pointer dereference. testsuite/ PR fortran/57033 * gfortran.dg/default_initialization_7.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/default_initialization_7.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/primary.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug other/59834] [4.9 Regression] g++.dg/cilk-plus/CK/catch_exc.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59834 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now: Author: jakub Date: Fri Feb 7 23:58:29 2014 New Revision: 207623 URL: http://gcc.gnu.org/viewcvs?rev=207623root=gccview=rev Log: * cilk-common.c (cilk_init_builtins): Clear TREE_NOTHROW flag on __cilkrts_rethrow builtin. Modified: trunk/gcc/ChangeLog trunk/gcc/cilk-common.c
[Bug fortran/57033] [4.7/4.8/4.9 Regression] ICE on extended derived type and default initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57033 --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Sat Feb 8 20:51:01 2014 New Revision: 207635 URL: http://gcc.gnu.org/viewcvs?rev=207635root=gccview=rev Log: fortran/ PR fortran/57033 * primary.c (gfc_convert_to_structure_constructor): Avoid null pointer dereference. testsuite/ PR fortran/57033 * gfortran.dg/default_initialization_7.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/default_initialization_7.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/primary.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/57033] [4.7/4.8/4.9 Regression] ICE on extended derived type and default initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57033 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Mikael Morin mikael at gcc dot gnu.org --- Fixed for 4.7.4, 4.8.3 and 4.9.0. Thanks for the report.
[Bug web/60119] New: Bugzilla URLs don't work with https.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60119 Bug ID: 60119 Summary: Bugzilla URLs don't work with https. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Example: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048 - Bug #57048 does not exist. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048 - PR57048 page
[Bug web/60119] Bugzilla URLs don't work with https.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60119 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed. I don't know if it is a bug or a feature.
[Bug web/60119] Bugzilla URLs don't work with https.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60119 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||overseers at gcc dot gnu.org --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- The problem is https://gcc.gnu.org still points to the web area of sourceware.org rather than gcc.gnu.org.
[Bug fortran/58470] [4.9 Regression] [OOP] ICE on invalid with FINAL procedure and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 --- Comment #6 from janus at gcc dot gnu.org --- Author: janus Date: Sat Feb 8 21:32:25 2014 New Revision: 207636 URL: http://gcc.gnu.org/viewcvs?rev=207636root=gccview=rev Log: 2014-02-08 Janus Weil ja...@gcc.gnu.org Mikael Morin mikael.mo...@gcc.gnu.org PR fortran/58470 * class.c (generate_finalization_wrapper): Assert that proc_tree has been set in gfc_resolve_finalizers. * resolve.c (resolve_fl_derived0): Remove unnecessary call to gfc_is_finalizable. 2014-02-08 Janus Weil ja...@gcc.gnu.org PR fortran/58470 * gfortran.dg/finalize_22.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/finalize_22.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/37336] [F03] Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Bug 37336 depends on bug 58470, which changed state. Bug 58470 Summary: [4.9 Regression] [OOP] ICE on invalid with FINAL procedure and type extension http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/58470] [4.9 Regression] [OOP] ICE on invalid with FINAL procedure and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from janus at gcc dot gnu.org --- Fixed with r207636. Closing.
[Bug fortran/59599] Compiler internal error on intrinsic ichar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59599
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3 from Mikael Morin mikael at gcc dot gnu.org ---
in trans-intrinsic's gfc_conv_intrinsic_function_args:
if (e-ts.type == BT_CHARACTER)
{
gfc_conv_expr (argse, e);
gfc_conv_string_parameter (argse);
argarray[curr_arg++] = argse.string_length;
gcc_assert (curr_arg nargs);
}
we evaluate the string lenth into argarray[curr_arg], but argarray[curr_arg] is
supposed to be the place where the next function argument lies. So in the
testcase, we don't evaluate the kind argument to ichar and all hell breaks
loose from that.
[Bug fortran/59599] Compiler internal error on intrinsic ichar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59599 --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Mikael Morin from comment #3) we evaluate the string lenth into argarray[curr_arg], s/lenth/length/ but argarray[curr_arg] is supposed to be the place where the next function argument lies. To be clear: it's the place where the next function argument will be put once evaluated, but we don't get to that point because curr_arg is bumped and we have the wanted number of arguments.
[Bug fortran/59599] Compiler internal error on intrinsic ichar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59599
--- Comment #5 from Mikael Morin mikael at gcc dot gnu.org ---
Patch:
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 1eb9490..1e1a137 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -4690,7 +4690,7 @@ gfc_conv_intrinsic_ichar (gfc_se * se, gfc_expr * expr)
{
tree args[2], type, pchartype;
- gfc_conv_intrinsic_function_args (se, expr, args, 2);
+ gfc_conv_intrinsic_function_args (se, expr, args, 3);
gcc_assert (POINTER_TYPE_P (TREE_TYPE (args[1])));
pchartype = gfc_get_pchar_type (expr-value.function.actual-expr-ts.kind);
args[1] = fold_build1_loc (input_location, NOP_EXPR, pchartype, args[1]);
[Bug fortran/59599] Compiler internal error on intrinsic ichar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59599 --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Mikael Morin from comment #5) Patch: doesn't work. :-(
[Bug fortran/59599] Compiler internal error on intrinsic ichar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59599
--- Comment #7 from Mikael Morin mikael at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #6)
(In reply to Mikael Morin from comment #5)
Patch:
doesn't work. :-(
ichar's kind argument is optional, so passing a constant number of arguments to
gfc_conv_intrinsic_function_args is bogus.
This is a stage1 bug anyway (non-regression).
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 1eb9490..cff8e89 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -4689,8 +4689,10 @@ static void
gfc_conv_intrinsic_ichar (gfc_se * se, gfc_expr * expr)
{
tree args[2], type, pchartype;
+ int nargs;
- gfc_conv_intrinsic_function_args (se, expr, args, 2);
+ nargs = gfc_intrinsic_argument_list_length (expr);
+ gfc_conv_intrinsic_function_args (se, expr, args, nargs);
gcc_assert (POINTER_TYPE_P (TREE_TYPE (args[1])));
pchartype = gfc_get_pchar_type (expr-value.function.actual-expr-ts.kind);
args[1] = fold_build1_loc (input_location, NOP_EXPR, pchartype, args[1]);
[Bug ipa/60120] New: wrong code (for code with the optimize attribute) at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60120
Bug ID: 60120
Summary: wrong code (for code with the optimize attribute) at
-Os on x86_64-linux-gnu in 32-bit mode
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc 4.8 branch miscompiles the following code that uses the
optimize attribute on x86_64-linux at -Os in 32-bit mode (but not 64-bit).
This is a regression from gcc 4.7.x and doesn't affect the current gcc trunk.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/su/software/local/gcc-4.8/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8/configure --enable-languages=c,c++
Thread model: posix
gcc version 4.8.3 20140208 (prerelease) [gcc-4_8-branch revision 207632] (GCC)
$
$ gcc -m32 -O1 small.c; a.out
2
$ gcc -m64 -Os small.c; a.out
2
$ gcc -m32 -Os small.c; a.out
1
$
$ gcc-4.7.3 -m32 -Os small.c; a.out
2
$ gcc-trunk -m32 -Os small.c; a.out
2
$
int printf (const char *, ...);
int a;
static int
fn1 (int p)
{
return p + 1;
}
static
__attribute__ ((optimize (1)))
int fn2 ()
{
for (; a 1; a = fn1 (1))
;
return 0;
}
__attribute__ ((optimize (0)))
int fn3 ()
{
fn1 (0);
fn2 ();
return 0;
}
int
main ()
{
fn3 ();
printf (%d\n, a);
return 0;
}
[Bug ipa/60120] wrong code (for code with the optimize attribute) at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60120
--- Comment #1 from Zhendong Su su at cs dot ucdavis.edu ---
Below is another testcase that very likely points to the same root cause, so I
also include it here. Hope it's useful to help diagnose the issue.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/su/software/local/gcc-4.8/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8/configure --enable-languages=c,c++
Thread model: posix
gcc version 4.8.3 20140208 (prerelease) [gcc-4_8-branch revision 207632] (GCC)
$
$ gcc -m32 -O1 small.c; a.out
$ gcc -m64 -Os small.c; a.out
$
$ gcc -m32 -Os small.c
$ timeout -s 9 10 a.out
Killed
$
$ gcc-4.7.3 -m32 -Os small.c; a.out
$ gcc-trunk -m32 -Os small.c; a.out
$
int a = 1;
static int
fn1 (int p1, short p2)
{
return p2 == 0 ? 0 : p1 / p2;
}
int
fn2 (int p)
{
return 0 ? 0 : p;
}
__attribute__ ((optimize (0)))
int fn3 ()
{
if (fn1 (fn2 (72260), a))
;
else
for (;;)
;
return 0;
}
int
main ()
{
fn3 ();
return 0;
}
[Bug tree-optimization/60115] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115
--- Comment #5 from Zhendong Su su at cs dot ucdavis.edu ---
(In reply to Jakub Jelinek from comment #2)
I have to use something like:
int a, b[1];
int
main ()
{
lbl:
for (; a; a--)
if (b[1000])
goto lbl;
return 0;
}
to actually successfully reproduce it. Anyway, started with r204458.
It also affects the current 4.8 branch that I just built (but not the 4.8
releases).
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/su/software/local/gcc-4.8/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8/configure --enable-languages=c,c++
Thread model: posix
gcc version 4.8.3 20140208 (prerelease) [gcc-4_8-branch revision 207632] (GCC)
$
$ gcc -O3 small.c; a.out
Segmentation fault (core dumped)
$
$ gcc-4.8.2 -O3 small.c; a.out
$ gcc-4.8.1 -O3 small.c; a.out
$ gcc-4.8.0 -O3 small.c; a.out
[Bug tree-optimization/60115] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 --- Comment #6 from Zhendong Su su at cs dot ucdavis.edu --- So, it's also a 4.8 regression.
[Bug c/60121] New: gcc does not warn an obvious out-of-bound array access at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121 Bug ID: 60121 Summary: gcc does not warn an obvious out-of-bound array access at -O0 and -O1 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu For the given testcase below, gcc doesn't warn the out-of-bound array access at -O0 and -O1, but does at -Os and above, while clang warns at all optimization levels. Since the out-of-bound access is obvious, I wonder whether gcc should also warn at -O0 and -O1. This affects the current gcc trunk and all earlier versions. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 4.9.0 20140208 (experimental) [trunk revision 207627] (GCC) $ $ gcc-trunk -Warray-bounds -O0 small.c $ gcc-trunk -Warray-bounds -O1 small.c $ $ gcc-trunk -Warray-bounds -Os small.c small.c: In function ‘main’: small.c:8:10: warning: array subscript is above array bounds [-Warray-bounds] if (b[613]) ^ $ $ clang-trunk -Warray-bounds -O0 small.c small.c:8:9: warning: array index 613 is past the end of the array (which contains 1 element) [-Warray-bounds] if (b[613]) ^ ~~~ small.c:1:1: note: array 'b' declared here int a, b[1]; ^ 1 warning generated. $
[Bug c/60121] gcc does not warn an obvious out-of-bound array access at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121
--- Comment #1 from Zhendong Su su at cs dot ucdavis.edu ---
Here is the testcase:
-
int a, b[1];
int
main ()
{
lbl:
for (; a; a--)
if (b[613])
goto lbl;
return 0;
}
[Bug tree-optimization/60115] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 --- Comment #7 from Zhendong Su su at cs dot ucdavis.edu --- Should I report the out-out-bound array access warning issue as a separate report? Thanks. Reported it as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121
[Bug middle-end/60121] gcc does not warn an obvious out-of-bound array access at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- I think this is expected. out of bounds warnings come not from the front-end but the middle-end and are designed not to warn about in dead code. This code is dead as a != 0 is always false.
[Bug tree-optimization/60115] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- LIM is pulling the out of bounds load out of the loop.
[Bug fortran/55916] Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
--- Comment #11 from Jouko Orava jouko.orava at iki dot fi ---
Just in case there are users who encounter this bug report,
here is the single-file workaround. Save the following as
nosegfault.c, and follow the instructions in the comments.
It can be compiled into a shared library used e.g. via LD_PRELOAD,
or into an object file and linked directly to a C or GNU Fortran
program, to fix the issue.
(It is trivial, so I consider it to be either uncopyrightable,
or if it is copyrightable, in the public domain.
It should still be smart enough to work on all architectures,
as long as GCC's __BIGGEST_ALIGNMENT__ is reliable.)
___
#include stdlib.h
#include string.h
#include malloc.h
#include errno.h
/* Compile to a dynamic library:
* gcc $FLAGS -fPIC -shared nosegfault.c \
* -Wl,-soname,libnosefault.so -o libnosegfault.so
* Install the dynamic library at e.g. /usr/local/lib/,
* sudo install -m 0644 libnosegfault.so /usr/local/lib/
* and you can use it via e.g.
* env LD_PRELOAD=/usr/local/lib/libnosegfault.so COMMAND [ ARGS .. ]
*
* Compile this into an object file:
* gcc $FLAGS -c nosegfault.c
* compile your application, adding
* nosegfault.o
* to the build or final linking command; for example,
* gfortran $FLAGS nosegfault.o -o program
*
* $FLAGS may be empty, or contain your preferred optimization flags.
* If you are compiling 32-bit code, remember to include -m32 in it.
*
* If you compile static binaries, use a copy of the libc.a file
* (mentioned in the error if you try to compile with the object file
* statically), with malloc, calloc, __libc_malloc, and __libc_calloc
* replaced by the objects in this file, using e.g. 'ar'.
*/
#if __BIGGEST_ALIGNMENT__ = 8
# error You don't need this, or your compiler options are wrong.
#elif __BIGGEST_ALIGNMENT__ = 16
# define ALIGNMENT 16
#elif __BIGGEST_ALIGNMENT__ = 32
# define ALIGNMENT 32
#elif __BIGGEST_ALIGNMENT__ = 64
# define ALIGNMENT 64
#else
# error Your architecture has insane alignment requirements.
#endif
void *malloc(size_t size)
{
return memalign(ALIGNMENT, size);
}
void *__libc_malloc(size_t size)
{
return memalign(ALIGNMENT, size);
}
void *calloc(size_t count, size_t size)
{
if (!count || !size) {
return NULL;
} else {
const size_t n = size * count;
if ((size_t)(n / size) == count) {
void *p = memalign(ALIGNMENT, n);
if (!p)
return NULL;
memset(p, 0, n);
return p;
}
errno = ENOMEM;
return NULL;
}
}
void *__libc_calloc(size_t count, size_t size)
{
if (!count || !size) {
return NULL;
} else {
const size_t n = size * count;
if ((size_t)(n / size) == count) {
void *p = memalign(ALIGNMENT, n);
if (!p)
return NULL;
memset(p, 0, n);
return p;
}
errno = ENOMEM;
return NULL;
}
}
/* The End. */
[Bug middle-end/60121] gcc does not warn an obvious out-of-bound array access at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121 --- Comment #3 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Andrew Pinski from comment #2) I think this is expected. out of bounds warnings come not from the front-end but the middle-end and are designed not to warn about in dead code. This code is dead as a != 0 is always false. Andrew, it's actually the complete opposite with this testcase. At -O0 and -O1, gcc unlikely knows that the out-of-bound array access is dead, so the warning should be issued, but it's not. On the other hand, at -Os and above, gcc likely knows that the out-of-bound array access is dead, but it warns.
[Bug fortran/60122] New: Unexpected warning for uninitialised character variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60122 Bug ID: 60122 Summary: Unexpected warning for uninitialised character variable Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fmartinez at gmv dot com The attahed code produces an unexpected warning. test.f90: In function ‘test’: test.f90:9:0: warning: ‘.s’ may be used uninitialized in this function [-Wmaybe-uninitialized] s = c ^ The build command is: /opt/gcc/bin/gfortran -c -Wall test.f90 The compiler version: Using built-in specs. COLLECT_GCC=/opt/gcc/bin/gfortran COLLECT_LTO_WRAPPER=/home/fran/compilers/gcc/gcc-4.9/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9-source/gcc-4.9-20140202/configure --enable-languages=c,c++,fortran --enable-checking=release --disable-libmudflap --disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold --with-plugin-ld=/usr/bin/gold --with-cloog-include=/usr/include-cloog --with-cloog-lib=/usr/lib64 --prefix=/usr/local/gcc-4.9 Thread model: posix gcc version 4.9.0 20140202 (experimental) (GCC)
[Bug fortran/60122] Unexpected warning for uninitialised character variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60122 --- Comment #1 from Fran Martinez Fadrique fmartinez at gmv dot com --- Created attachment 32085 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32085action=edit Test case
[Bug fortran/60122] Unexpected warning for uninitialised character variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60122 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Actually the reason for the warning is due to LIM pulling the out of bounds access out of the loop, the same reason why bug 60115 fails. *** This bug has been marked as a duplicate of bug 60115 ***
[Bug tree-optimization/60115] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||fmartinez at gmv dot com --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 60122 has been marked as a duplicate of this bug. ***
[Bug middle-end/60121] gcc does not warn an obvious out-of-bound array access at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Actually the reason for the warning is due to LIM pulling the out of bounds access out of the loop, the same reason why bug 60115 fails. It is just showing the bug a different way. *** This bug has been marked as a duplicate of bug 60115 ***
[Bug fortran/60122] Unexpected warning for uninitialised character variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60122 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Woops wrong bug.
[Bug tree-optimization/60115] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 60121 has been marked as a duplicate of this bug. ***
[Bug middle-end/60121] gcc does not warn an obvious out-of-bound array access at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121 --- Comment #5 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Andrew Pinski from comment #4) Actually the reason for the warning is due to LIM pulling the out of bounds access out of the loop, the same reason why bug 60115 fails. It is just showing the bug a different way. *** This bug has been marked as a duplicate of bug 60115 *** Andrew, you completely lost me ... Please note that this warning issue affects ALL earlier versions of GCC too, but 60115 only for the current 4.8 branch and the main trunk. Please check the report carefully. Thanks.
[Bug target/60028] TIC6X: B3 register (return address) is saved on stack when real call is replaced with sibling call in a leaf function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60028
Wojciech Migda wojtek.golf at interia dot pl changed:
What|Removed |Added
Target||tic6x-none-elf
Host||Linux wmigda-desktop
||3.11.0-13-generic
||#20-Ubuntu SMP Wed Oct 23
||17:26:33 UTC 2013 i686 i686
||i686 GNU/Linux
Version|4.8.2 |4.9.0
Build||tic6x-none-elf-gcc (GCC)
||4.9.0 20140208
||(experimental)
--- Comment #1 from Wojciech Migda wojtek.golf at interia dot pl ---
I have recreated the scenario on the latest 4.9.0 shanpshot, hence the changes
in the headline/description.
=
Exact version of gcc:
tic6x-none-elf-gcc (GCC) 4.9.0 20140208 (experimental)
System type:
Linux wmigda-desktop 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 17:26:33 UTC
2013 i686 i686 i686 GNU/Linux
Options given when gcc was built:
export TRIPLET=tic6x-none-elf
mkdir -pv ${X_BUILD_DIR}/gcc-${GCC_VER}-build-pass-1/
pushd ${X_BUILD_DIR}gcc-${GCC_VER}-build-pass-1/ \
RANLIB_FOR_TARGET=${CXTOOLS}bin/${TRIPLET}-ranlib
AS_FOR_TARGET=${CXTOOLS}bin/${TRIPLET}-as
AR_FOR_TARGET=${CXTOOLS}bin/${TRIPLET}-ar \
AS=as AR=ar LDFLAGS='-lstdc++ -lm' ../../../../gcc/configure \
--prefix=${C_TOOLS} \
--build=$(gcc -dumpmachine) \
--host=$(gcc -dumpmachine) \
--target=${TRIPLET} \
--with-local-prefix=${CXTOOLS}${TRIPLET}/sysroot \
--with-sysroot=${CXTOOLS}${TRIPLET}/sysroot \
--disable-nls \
--disable-shared \
--without-headers \
--with-newlib \
--disable-decimal-float \
--disable-libgomp \
--disable-libmudflap \
--disable-libssp \
--disable-libatomic \
--disable-libquadmath \
--disable-threads \
--enable-languages=c \
--disable-multilib \
--with-mpfr=${C_TOOLS} \
--with-gmp=${C_TOOLS} \
--disable-__cxa_atexit \
--disable-sjlj-exceptions \
--enable-target-optspace \
--disable-libstdcxx-pch \
; popd
Commandline:
tic6x-none-elf-gcc -fleading-underscore -march=c674x -O2 -g0 -S main.c
Compiler output:
nothing one the console
Preprocessed file:
# 1 main.c
# 1 command-line
# 1 main.c
int e_fun(int arg);
extern int e_int;
void g_fun(void)
{
e_fun(e_int);
}
[Bug middle-end/60121] gcc does not warn an obvious out-of-bound array access at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121
--- Comment #6 from Chengnian Sun chengniansun at gmail dot com ---
The test case can be further reduced to the following code, which is NOT dead
or dependent on bug 60115.
int b[1];
int f() {
return b[];
}
[Bug target/60123] New: TIC6x: EABI incompatibility when large struct is returned from function and is not used by the caller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60123
Bug ID: 60123
Summary: TIC6x: EABI incompatibility when large struct is
returned from function and is not used by the caller
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wojtek.golf at interia dot pl
=
Exact version of gcc:
tic6x-none-elf-gcc (GCC) 4.9.0 20140208 (experimental)
System type:
Linux wmigda-desktop 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 17:26:33 UTC
2013 i686 i686 i686 GNU/Linux
Options given when gcc was built:
export TRIPLET=tic6x-none-elf
mkdir -pv ${X_BUILD_DIR}/gcc-${GCC_VER}-build-pass-1/
pushd ${X_BUILD_DIR}gcc-${GCC_VER}-build-pass-1/ \
RANLIB_FOR_TARGET=${CXTOOLS}bin/${TRIPLET}-ranlib
AS_FOR_TARGET=${CXTOOLS}bin/${TRIPLET}-as
AR_FOR_TARGET=${CXTOOLS}bin/${TRIPLET}-ar \
AS=as AR=ar LDFLAGS='-lstdc++ -lm' ../../../../gcc/configure \
--prefix=${C_TOOLS} \
--build=$(gcc -dumpmachine) \
--host=$(gcc -dumpmachine) \
--target=${TRIPLET} \
--with-local-prefix=${CXTOOLS}${TRIPLET}/sysroot \
--with-sysroot=${CXTOOLS}${TRIPLET}/sysroot \
--disable-nls \
--disable-shared \
--without-headers \
--with-newlib \
--disable-decimal-float \
--disable-libgomp \
--disable-libmudflap \
--disable-libssp \
--disable-libatomic \
--disable-libquadmath \
--disable-threads \
--enable-languages=c \
--disable-multilib \
--with-mpfr=${C_TOOLS} \
--with-gmp=${C_TOOLS} \
--disable-__cxa_atexit \
--disable-sjlj-exceptions \
--enable-target-optspace \
--disable-libstdcxx-pch \
; popd
Commandline:
tic6x-none-elf-gcc -fleading-underscore -march=c674x -O2 -g0 -S main.c
Compiler output:
nothing one the console
Preprocessed file:
# 1 main.c
# 1 command-line
# 1 main.c
typedef struct A
{
long long y;
char z;
} struct_A;
extern struct_A e_struct1;
struct_A g_fun_6(void)
{
return e_struct1;
}
The problem:
SPRAB89 document from Texas Instruments states that:
If the called function returns a structure or union larger than 64 bits, the
caller must pass an additional argument in A3 containing a destination address
for the returned value, or 0 if the returned value is not used. The callee
returns the object by copying it to the address in A3, if non-zero.
Assembler listing generated by gcc doesn't check for the passed address being
non-NULL:
_g_fun_6:
mvkl.s1 (_e_struct1), A5
|| mv .d1 A3, A4
mvkh.s1 (_e_struct1), A5
lddw.d1t1 *A5, A7:A6
lddw.d1t1 *+A5(8), A9:A8
|| ret .s2 B3
nop 3
stdw.d1t1 A7:A6, *A3
stdw.d1t1 A9:A8, *+A3(8)
whereas assembler generated by TI CGTools' cl6x compiler does. Hence, if the
code compiled with cl6x calls code produced by gcc a NULL pointer write will
occur.
Also, in the assembler above copying A3 to A4 (mv .d1 A3, A4) doesn't relate
to anything and could be eliminated altogether.
[Bug middle-end/60121] gcc does not warn an obvious out-of-bound array access at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121
--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Chengnian Sun from comment #6)
The test case can be further reduced to the following code, which is NOT
dead or dependent on bug 60115.
int b[1];
int f() {
return b[];
}
Because we don't warn in the front-end. That was on purpose. I can find the
old bug reports of why we don't want to warn in the front-end. The warning
only happens in VPR which is only enabled for -O2 and above (-Os is -O2 plus
optimize for size really).
[Bug middle-end/60121] gcc does not warn an obvious out-of-bound array access at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121
--- Comment #8 from Chengnian Sun chengniansun at gmail dot com ---
(In reply to Andrew Pinski from comment #7)
(In reply to Chengnian Sun from comment #6)
The test case can be further reduced to the following code, which is NOT
dead or dependent on bug 60115.
int b[1];
int f() {
return b[];
}
Because we don't warn in the front-end. That was on purpose. I can find
the old bug reports of why we don't want to warn in the front-end. The
warning only happens in VPR which is only enabled for -O2 and above (-Os is
-O2 plus optimize for size really).
Thanks. Is it possible to enable vrp with -ftree-vrp at -O0 level? Therefore
the user can get this warning even when the code is not optimized?
[Bug libfortran/52879] Pathological reseeding of PRNG generator genernates poor sequence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879 --- Comment #2 from kargl at gcc dot gnu.org --- Potential patch http://gcc.gnu.org/ml/fortran/2014-02/msg00047.html
[Bug web/60119] Bugzilla URLs don't work with https.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60119 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||fche at redhat dot com Resolution|--- |INVALID --- Comment #3 from Frank Ch. Eigler fche at redhat dot com --- Until we can get hold of a x509 certificate for the gcc.gnu.org domain (i.e., via someone from the FSF, who holds the gnu.org admin contacts), sourceware.org can only serve https for that alter ego. (A self-signed key is another possibility, but no one's too keen on that.)
[Bug middle-end/60121] gcc does not warn an obvious out-of-bound array access at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60121 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- No. VRP isn't really a cheap pass and for -O0 the most important thing is compile time speed. GCC has never guaranteed the same warnings between optimization levels, for frontend warnings it is sometimes possible to have the same warnings, but for middle-end warnings it is not possible and never a goal. Think say about uninitialized warnings, some of them heavily depend on which functions are inlined and which are not.
