[Bug c++/77543] ARM: G++ generates redundant instructions at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77543 --- Comment #2 from Michael Haben --- "eh" being exception handling? Is there any command-line switch that will turn off generation of this "tree" thing in code that doesn't (and can't) use exceptions (e.g. ARM microcontroller code, for which GCC is very widely used)? Thanks, Mike H.
[Bug middle-end/77426] Duplicate condition in expmed.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77426 --- Comment #4 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Sep 12 08:17:27 2016 New Revision: 240089 URL: https://gcc.gnu.org/viewcvs?rev=240089&root=gcc&view=rev Log: [expmed.c] PR middle-end/77426 Delete duplicate condition in synth_mult PR middle-end/77426 * expmed.c (synth_mult): Delete duplicate mode check. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 Bug 77421 depends on bug 77426, which changed state. Bug 77426 Summary: Duplicate condition in expmed.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77426 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/77426] Duplicate condition in expmed.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77426 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/77543] ARM: G++ generates redundant instructions at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77543 --- Comment #3 from Andrew Pinski --- Yes try -fno-exceptions . This is all documented already and 99% of folks who do embedded that don't want exceptions already use that flag. You might also want to disable rtti too.
[Bug libgcc/68082] issue on 64 bit shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68082 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #8 from Andrew Pinski --- So close as invalid for this bug.
[Bug c++/77563] New: explicit constructor breaks narrowing conversion overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77563
Bug ID: 77563
Summary: explicit constructor breaks narrowing conversion
overload resolution
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arnetheduck at gmail dot com
Target Milestone: ---
In the following snippet, an error should be emitted - instead, the compiler
prints a warning and keeps compiling, and simply skips the second call to f (!)
in the resulting executable:
#include
#include
struct A {
A(int32_t a) {}
A(uint32_t a) {} // Comment to make it work
explicit A(int64_t a) {} // Comment to make it work
};
void f(A a) { printf("hello\n"); }
int main(int, char**) {
f(2);
f(3l);
}
/opt/gcc62/bin/g++ -std=gnu++11 explicit.cpp
explicit.cpp: In function ‘int main(int, char**)’:
explicit.cpp:11:6: note: initializing argument 1 of ‘void f(A)’
void f(A a) { printf("hello\n"); }
^
With either marked constructor commented, compiles correctly and gives the
expected output ("hello" x 2 or ambiguity error).
[Bug c++/77563] explicit constructor breaks narrowing conversion overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77563
--- Comment #1 from Jacek Sieka ---
gcc 5.3.0 gives a different error - looks odd though, no initializer list in
sight:
/opt/gcc53/bin/g++ -std=gnu++11 explicit.cpp
explicit.cpp: In function ‘int main(int, char**)’:
explicit.cpp:15:7: error: converting to ‘A’ from initializer list would use
explicit constructor ‘A::A(int64_t)’
f(3l);
^
explicit.cpp:11:6: note: initializing argument 1 of ‘void f(A)’
void f(A a) { printf("hello\n"); }
^
clang++ 3.8 complains about ambiguity:
clang++ -std=gnu++11 explicit.cpp
explicit.cpp:15:5: error: conversion from 'long' to 'A' is ambiguous
f(3l);
^~
explicit.cpp:5:3: note: candidate constructor
A(int32_t a) {}
^
explicit.cpp:6:3: note: candidate constructor
A(uint32_t a) {}
^
explicit.cpp:11:10: note: passing argument to parameter 'a' here
void f(A a) { printf("hello\n"); }
[Bug libstdc++/77528] std::queue default constructor unnecessarily creates temporary of underlying Container
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77528 --- Comment #3 from Jonathan Wakely --- (In reply to TC from comment #2) > This makes the default constructor implicit, Yes, that was intentional :-) > though that's probably how it > should be anyway. Yes, we missed the container adaptors when fixing https://wg21.link/lwg2193
[Bug tree-optimization/67607] Failure to perform constant folding through type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/67612] Unable to vectorize DOT_PROD_EXPR (PMADDWD?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67612 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/77543] ARM: G++ generates redundant instructions at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77543 --- Comment #4 from Michael Haben --- (In reply to Andrew Pinski from comment #3) > Yes try -fno-exceptions . This is all documented already and 99% of folks > who do embedded that don't want exceptions already use that flag. You might > also want to disable rtti too. Yes, I already use both of those but still get the "extra" code - I was hoping you might know of another "-f" switch that was more specific.
[Bug c++/67596] /usr/include/c++/4.7/bits/stl_list.h error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67596 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- no feedback in over 3 months (almost a year now) so closing.
[Bug tree-optimization/63945] Missing vectorization optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63945 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479 --- Comment #16 from Jonathan Wakely --- (In reply to Eric Gallager from comment #14) > (In reply to Manuel López-Ibáñez from comment #9) > > In summary, neither adding 'default' or 'return' are recommended to silence > > this warning if you think the warning is wrong. If you think the warning > > will always be wrong, use __builtin_unreachable(). If you think it is wrong > > now, but you would like to notice if it stops being wrong, then use > > assert(false). > > > This is probably an issue for a separate bug, but speaking of > __builtin_unreachable(), now that GCC is going to start recognizing the > lint-style comment of: > /* FALLTHROUGH */ > for the benefit of -Wimplicit-fallthrough, could it also start recognizing > the lint-style comment of: > /* NOTREACHED */ > as a synonym for __builtin_unreachable()? I've seen comments like that in a > lot of code, actually, and it'd be a more portable solution than > __builtin_unreachable(). No No No No :-) Recognising comments like "FALLTHROUGH" and "fall-through" is a pragmatic solution to avoid introducing new false-positive warnings for old code that works as designed. (New code C++ should use [[attributes]] not comments, and C code can use GNU __attributes__, and [[attributes]] have been proposed for C too). Comments should not alter codegen, which __builtin_unreachable does. Also, NOTREACHED is IME just one of countless variations on comments such as "We should never get here" and "If we get here it's a bug" etc. and matching such arbitrary comments in infeasible.
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #17 from Jonathan Wakely ---
(In reply to DB from comment #12)
> (In reply to Jonathan Wakely from comment #11)
> > Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> > -fstrict-enums tells the compiler it will never have a value outside that
> > range. It does **not** tell it that the type will never have the value 0 or
> > 2.
>
> Huh. So allows non-named values and only enforces min/max, so doesn't
> account for folk doing bitwise ORing?
Huh? I have no idea what you mean by doesn't account for bitwide ORing. The
fact you can have non-named values is essential for bitwide ORing.
enum Bitmask { bit1 = 1, bit2 = 2, bit4 = 4 };
Bitmask b = Bitmask(bit1|bit4);
This creates a value that doesn't correspond to a named enumerator, but
obviously this is valid. (For this type the values of the type are [0,7]
because 7 is the highest value that can be represented in the minimum number of
bits needed to represent all the enumerators).
That's how enumerated types work in C++, although many people seem to
misunderstand them. Enumerations are simply named constants, they don't affect
the type, or codegen, or what the valid values of the type are (except where
the values of the highest and lowest determine the range of valid values).
(In reply to Eric Gallager from comment #15)
> (In reply to Jonathan Wakely from comment #11)
> > (In reply to Eric Gallager from comment #6)
> > > This should probably depend on the -fstrict-enums flag, as that controls
> > > whether enums can have any value or just those values that are enumerated.
> >
> > No, that's not what it does.
> >
> > It tells the compiler the enum will only be one of the values of the
> > enumeration, which is not the same as the values corresponding to
> > enumerators.
> >
>
>
> That's a confusing distinction; they sound like the same thing at first to
> someone like me who doesn't speak standards-ese...
Well ... it's not.
> > As I said in comment 3, the OP's type has the values of int, because it has
> > an underlying type of int.
> >
> > Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> > -fstrict-enums tells the compiler it will never have a value outside that
> > range. It does **not** tell it that the type will never have the value 0 or
> > 2.
>
>
> Thanks, that example helps clear things up. Could it be added to the
> documentation for -fstrict-enums?
It already says "the values of the enumeration (as defined in the C++ standard;
basically, a value that can be represented in the minimum number of bits needed
to represent all the enumerators)."
The minimum number of bits needed to represent E1 and E3 is two bits, and both
0 and 2 can be represented in two bits.
Can I request that any further discussion happens elsewhere (the gcc-help list
or a general C++ programming forum) because it doesn't belong here.
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #18 from DB ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to DB from comment #12)
> > (In reply to Jonathan Wakely from comment #11)
> > > Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3
> > > and
> > > -fstrict-enums tells the compiler it will never have a value outside that
> > > range. It does **not** tell it that the type will never have the value 0
> > > or
> > > 2.
> >
> > Huh. So allows non-named values and only enforces min/max, so doesn't
> > account for folk doing bitwise ORing?
>
> Huh? I have no idea what you mean by doesn't account for bitwide ORing. The
> fact you can have non-named values is essential for bitwide ORing.
>
> enum Bitmask { bit1 = 1, bit2 = 2, bit4 = 4 };
> Bitmask b = Bitmask(bit1|bit4);
>
> This creates a value that doesn't correspond to a named enumerator, but
> obviously this is valid. (For this type the values of the type are [0,7]
> because 7 is the highest value that can be represented in the minimum number
> of bits needed to represent all the enumerators).
My doubt ultimately arose from a momentary fail at bitwise arithmetic (thinking
1 | 3 == 4, how embarrassing), but I'm glad it elicited this confirmation!
Thanks.
[Bug ipa/70582] [6/7 regression] gcc.dg/attr-weakref-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70582 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Jan Hubicka --- > Does this still reproduce? I have implemented the optimization that removes > weakrefs with definition provided in other unit so this may be solved/hidden > by > it. I've just rechecked current mainline (r240088) and the failure persists. Rainer
[Bug c++/77564] New: Code fails to link when compiled with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77564
Bug ID: 77564
Summary: Code fails to link when compiled with -O0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: csaba_22 at yahoo dot co.uk
Target Milestone: ---
The following code fails to link when compiled with -O0. It links when compiled
with -O1 or higher, or -Og:
template
class du {
R r;
public:
constexpr du() = default;
du(const du&) = default;
template
constexpr explicit du(const R2& rep)
: r(static_cast(rep)) { }
};
typedef du secs;
class DWP {
secs to;
public:
DWP(secs x);
};
DWP::DWP(secs x)
: to(x)
{}
class FHT {
public:
FHT()
: dwp{secs(READ_TIMEOUT)}
{}
protected:
static auto constexpr READ_TIMEOUT = 1;
DWP dwp;
};
int main()
{
FHT fht;
}
$ g++-620 -Wall -pedantic -Wextra -std=c++11 constexpr.cc -o constexpr
/tmp/ccoUUTbu.o: In function `FHT::FHT()':
constexpr.cc:(.text._ZN3FHTC2Ev[_ZN3FHTC5Ev]+0x11): undefined reference to
`FHT::READ_TIMEOUT'
$ nm constexpr.o | c++filt
0017 T main
W du::du(int const&)
T DWP::DWP(du)
T DWP::DWP(du)
U FHT::READ_TIMEOUT
W FHT::FHT()
W FHT::FHT()
n FHT::FHT()
If compiling with -O1:
$ nm constexpr.o | c++filt
0003 T main
T DWP::DWP(du)
T DWP::DWP(du)
Seen with a hand-built GCC 6.2:
$ g++-620 -v
Using built-in specs.
COLLECT_GCC=g++-620
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.2.0/configure --program-suffix=-620
--enable-version-specific-runtime-libs --enable-languages=c,c++,lto
Thread model: posix
gcc version 6.2.0 (GCC)
This has been seen with GCC as far back as
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
[Bug c++/77565] New: `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 Bug ID: 77565 Summary: `typdef int Int;` --> did you mean `typeof`? Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mimomorin at gmail dot com Target Milestone: --- Compiling `typdef int Int;` on gcc 7.0.0 (20160904) gives this message: error: 'typedeff' does not name a type; did you mean 'typeof'? I would expect "did you mean 'typedef'?", instead. Note that the edit distance between `typdef` and `typedef` is smaller than the one between `typdef` and `typeof`. So I think it's a bit strange that the compiler suggests `typeof`.
[Bug c++/77564] Code fails to link when compiled with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77564 --- Comment #1 from Andrew Pinski --- I suspect you need a definition of FHT::READ_TIMEOUT, not just a declaration of it.
[Bug c++/77566] New: Warnings (-Wextra) disappear for a public reference to the this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77566
Bug ID: 77566
Summary: Warnings (-Wextra) disappear for a public reference to
the this pointer
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michele.caini at gmail dot com
Target Milestone: ---
I'm referring to this question on SO:
http://stackoverflow.com/questions/39449946/reference-to-the-this-pointer-gcc-vs-clang
The following code compiles with warnings with -Wextra:
struct A {
private:
A* const& this_ref{this};
};
int main() {
A a{};
(void)a;
}
Relevant warning:
/data/user/0/com.n0n3m4.droidc/files/temp.c: In constructor 'constexpr A::A()':
/data/user/0/com.n0n3m4.droidc/files/temp.c:1:8: warning: a temporary bound to
'A::this_ref' only persists until the constructor exits [-Wextra]
struct A {
^
The following code (public data member) has no warning instead:
struct A {
A* const& this_ref{this};
};
int main() {
A a{};
(void)a;
}
I guess the same diagnostic issue should be detected for the second snippet.
[Bug ipa/61159] __builtin_constant_p gives incorrect results with aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #5 from Rainer Orth --- The new testcase FAILs on Solaris/x86 with /bin/as: FAIL: gcc.c-torture/compile/pr61159.c -O0 (test for excess errors) Excess errors: Assembler: pr61159.c "/var/tmp//ccRtFPva.s", line 5 : Cannot set a weak symbol to a common symbol Input is .file "pr61159.c" .local dummy .comm dummy,4,4 .weak foo .setfoo,dummy Rainer
[Bug c++/67466] Project segfaulting, working with other compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67466 --- Comment #1 from Andrew Pinski --- Have you figured out what is going on? Or is your code still broken with GCC 5.x? Does it work at -O0?
[Bug c/67488] Incorrect error message on call of nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67488 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Andrew Pinski --- I actually think gcc's diagnostic is clearer; at least from a standard point of view. It is pointing out where the previous definition is located. All it might add is that was in a different scope and that would fix this bug.
[Bug c/71199] Support overloadable attribute in GNU C front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199 --- Comment #9 from Bill Schmidt --- (In reply to Yu Xuanchi from comment #6) > So I think in short term. We just reject those code. Because our aim is to > support this feature like clang. If there is no any problem. I'll go impl it. Agreed, we really don't care about this nested case, so rejecting it as Clang does seems appropriate to me.
[Bug c/67488] Incorrect error message on call of nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67488
--- Comment #3 from Andrew Pinski ---
A similar fix would be good for:
void g() {
void f(void);
}
void k() {int f(int); f(1);}
Saying f was declared in a different scope too.
Note I don't have access to clang so I can't say what it shows.
[Bug c/67488] Improve diagnostic on call of declared function in a different scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67488 Andrew Pinski changed: What|Removed |Added Summary|Incorrect error message on |Improve diagnostic on call |call of nested functions|of declared function in a ||different scope --- Comment #4 from Andrew Pinski --- Note the error is not incorrect, clang is wrong in not rejecting the code but that is a different story.
[Bug c++/67466] Project segfaulting, working with other compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67466 morandidodo at gmail dot com changed: What|Removed |Added Known to work||6.2.1 Known to fail||5.2.0 --- Comment #2 from morandidodo at gmail dot com --- I am sorry, but it has been more than an year and now I am using GCC 6.2.1, I am not able to reproduce the bug anymore. Indeed, the new version seems to work flawlessly, and I do not get segfaults even with the address sanitizer. If someone have the 5.x branch installed, the Voxelands commit which caused the problem was the fa519dee2751b46ee36f4443d5b194dbbe1dd1e5. Otherwise, I could close the issue. I do not know if it is worth to track down strange and uncommon issues with an old version of the compiler...
[Bug c++/77564] Code fails to link when compiled with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77564 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- Right, the code is invalid. This is a FAQ. See https://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-12 Ever confirmed|0 |1
[Bug lto/60016] gcc-nm does not report static symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60016 --- Comment #2 from Andi Kleen --- This is needed for example to generate backtraces, if the symbol table should be built in instead of read from the binary. The Linux kernel cannot read its own binary, so the symbol table has to built in.
[Bug c++/77543] ARM: G++ generates redundant instructions at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77543 --- Comment #5 from Michael Haben --- (In reply to Michael Haben from comment #4) > (In reply to Andrew Pinski from comment #3) > > Yes try -fno-exceptions . This is all documented already and 99% of folks > > who do embedded that don't want exceptions already use that flag. You might > > also want to disable rtti too. > > Yes, I already use both of those but still get the "extra" code - I was > hoping you might know of another "-f" switch that was more specific. By trial-and-error, found that -O0 -ftree-ter (Temporary Expression Replacement) does what I want.
[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug sanitizer/77567] New: ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs operator delete [])" with C++17's over-aligned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77567
Bug ID: 77567
Summary: ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs
operator delete [])" with C++17's over-aligned types
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, jason at gcc dot gnu.org, kcc at
gcc dot gnu.org
Target Milestone: ---
In my understanding, the following is valid C++17:
#include
int main() {
char *c = new(std::align_val_t(512), std::nothrow) char[1024];
delete[] c;
return 0;
}
However, compiling with "g++ -fsanitize=address -std=c++17 test.cc" shows at
run time:
==16736==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator
delete []) on 0x61b1f200
[Bug c/72858] incorrect fixit hints in -Wformat diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72858 --- Comment #2 from David Malcolm --- Author: dmalcolm Date: Mon Sep 12 16:01:02 2016 New Revision: 240095 URL: https://gcc.gnu.org/viewcvs?rev=240095&root=gcc&view=rev Log: Fix suggestions for non-trivial Wformat type cases (PR c/72858) gcc/c-family/ChangeLog: PR c/72858 * c-format.c (argument_parser::check_argument_type): Add params "type_start" and "conversion_char". Use the former to generate offset_to_type_start and pass it and conversion_char to check_format_types. (check_format_info_main): Capture the start of the type information as "type_start", and pass it an format_char to arg_parser.check_argument_type. (check_format_types): Provide an example in the leading comment. Add params "offset_to_type_start" and "conversion_char"; pass them to format_type_warning calls. (test_get_modifier_for_format_len): Likewise. (matching_type_p): New function. (get_format_for_type): Add param "conversion_char" and move implementation into... (get_format_for_type_1): ...new function, called twice. Use new function matching_type_p rather than checking for TYPE_CANONICAL equality. (get_corrected_substring): New function. (format_type_warning): Provide an example in the leading comment. Add params "offset_to_type_start" and "conversion_char". Replace call to get_format_for_type with call to get_corrected_substring and move rejection of hints for widths/precisions there. (assert_format_for_type_streq): Add param "conversion_char". (ASSERT_FORMAT_FOR_TYPE_STREQ): Add param CONVERSION_CHAR. (test_get_format_for_type_printf): Add conversion chars to the tests, adding coverage for various combinations of integer vs double conversions, and for preserving octal and hexadecimal conversions. (test_get_format_for_type_scanf): Add conversion chars to the tests. gcc/testsuite/ChangeLog: PR c/72858 * gcc.dg/format/diagnostic-ranges.c: Update expected suggestions to preserve conversion chars, and to preserve prefix information. * gcc.dg/format/pr72858.c: New test case. Added: trunk/gcc/testsuite/gcc.dg/format/pr72858.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-format.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/format/diagnostic-ranges.c
[Bug c/72858] incorrect fixit hints in -Wformat diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72858 --- Comment #3 from David Malcolm --- (In reply to David Malcolm from comment #2) > Author: dmalcolm > Date: Mon Sep 12 16:01:02 2016 > New Revision: 240095 The above commit fixes many of these issues; Martin identified some further improvements here: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01587.html which I'll quote inline here: On Mon, 2016-08-22 at 15:54 -0600, Martin Sebor wrote: > A couple of things I noticed when getting the -Wformat-length code > to use the new infrastructure from c-format. > > Hints that suggest alternate directives that don't accept all > the same flags as those used in the original should filter out > those flags. For example, when passing a pointer to a "%#lx" > directive, the hint should suggest "%s" for character pointers > and "%p" for others rather than "%#s" or "%#p". Similarly, > when passing a string to a "%+i" or "% i" directive, the '+' > and space flags should be removed. > > Also, with -Wformat-signedness (but I'd say without it as well), > the hints should respect the signedness of the arguments. For > example, the hint for "%u" with a long int argument should be > "%lu" and not "%li". > > Martin Keeping this bug open until these are addressed.
[Bug libgcc/67336] Verify pointers during stack unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67336 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-12 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- .
[Bug sanitizer/67899] build failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67899 --- Comment #7 from Mikael Pettersson --- Patch posted: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00647.html
[Bug sanitizer/77567] ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs operator delete [])" with C++17's over-aligned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77567 --- Comment #1 from Jakub Jelinek --- I guess libasan needs to add the new C++17 aligned new operator entrypoints. Dmitry, are you going to add this upstream yourself, or should I cook a patch?
[Bug sanitizer/77567] ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs operator delete [])" with C++17's over-aligned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77567 --- Comment #2 from Kostya Serebryany --- (In reply to Jakub Jelinek from comment #1) > I guess libasan needs to add the new C++17 aligned new operator entrypoints. > Dmitry, are you going to add this upstream yourself, or should I cook a > patch? Jaukub, yes, a patch upstream would be welcome. In clang we don't have -std=c++17 yet, so I won't even be able to test it there.
[Bug middle-end/77568] New: [7 regression] CSE/PRE/Hoisting blocks common instruction contractions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77568
Bug ID: 77568
Summary: [7 regression] CSE/PRE/Hoisting blocks common
instruction contractions
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wdijkstr at arm dot com
Target Milestone: ---
The recently introduced code hoisting aggressively moves common subexpressions
that might otherwise be mergeable with other operations. This caused a large
regression in one benchmark. A simple reduced test shows the issue:
float f(float x, float y, float z, int a)
{
if (a > 100)
x += y * z;
else
x -= y * z;
return x;
}
This now produces on AArch64:
f:
fmuls2, s1, s2
cmp w0, 100
fadds1, s0, s2
fsubs0, s0, s2
fcsel s0, s0, s1, le
ret
Note the issue is not limited to hoisting, CSE/PRE cause similar issues:
void g(int, int);
int f2(int x)
{
g(x, x+1);
g(x, x+1);
return x+1;
}
f2:
stp x29, x30, [sp, -32]!
add x29, sp, 0
stp x19, x20, [sp, 16]
add w19, w0, 1
mov w20, w0
mov w1, w19
bl g
mov w1, w19
mov w0, w20
bl g
mov w0, w19
ldp x19, x20, [sp, 16]
ldp x29, x30, [sp], 32
ret
Given x+1 is used as a function argument, there is no benefit in making it
available as a CSE after each call - repeating the addition is cheaper than
using an extra callee-save and copying it several times.
This shows a similar issue for bit tests. Most targets support ANDS or bit test
as a single instruction (or even bit test+branch), so CSEing the (x & C)
actually makes things worse:
void f3(char *p, int x)
{
if (x & 1) p[0] = 0;
if (x & 2) p[1] = 0;
if (x & 4) p[2] = 0;
if (x & 8) p[2] = 0;
g(0,0);
if (x & 1) p[3] = 0;
if (x & 2) p[4] = 0;
if (x & 4) p[5] = 0;
if (x & 8) p[6] = 0;
}
This uses 4 callee-saves to hold the (x & C) CSEs. Doing several such bit tests
in a more complex function means you quickly run out of registers...
Given it would be much harder to undo these CSEs at RTL level (combine does
most contractions but can only do it intra-block), would it be reasonable to
block CSEs for these special cases?
[Bug middle-end/77568] [7 regression] CSE/PRE/Hoisting blocks common instruction contractions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77568 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |7.0 --- Comment #1 from Andrew Pinski --- I think this is just a pass ordering issue. We create fmas after PRE. Maybe we should do it both before and after ... Or enhance the pass which produces FMA to walk through to another bb ...
[Bug middle-end/77568] [7 regression] CSE/PRE/Hoisting blocks common instruction contractions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77568 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-12 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Note there are two different issues here. One for the FMA issue which can/should be solved at the tree level (and that is a regression). The other is the CSE, we should be able to uncse (rematization) during register allocation to reduce register pressure; I think this has been filed already.
[Bug middle-end/77568] [7 regression] CSE/PRE/Hoisting blocks common instruction contractions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77568 --- Comment #3 from Wilco --- (In reply to Andrew Pinski from comment #1) > I think this is just a pass ordering issue. We create fmas after PRE. > Maybe we should do it both before and after ... > Or enhance the pass which produces FMA to walk through to another bb ... FMAs are not created in the tree, Expand can do simple cases, and Combine finds other cases. Given more and more targets support FMA, there is certainly an argument for adding an FMA tree operator.
[Bug middle-end/77568] [7 regression] CSE/PRE/Hoisting blocks common instruction contractions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77568 --- Comment #4 from Andrew Pinski --- For floating point they are definitely created on the gimple level. For ints they are not though. Maybe extend that same pass to do ints too for aarch64 and other targets which have a multiple add (mips).
[Bug middle-end/77568] [7 regression] CSE/PRE/Hoisting blocks common instruction contractions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77568 --- Comment #5 from Wilco --- (In reply to Andrew Pinski from comment #2) > Note there are two different issues here. Well they are 3 examples of the same underlying issue - don't do a CSE when it's not profitable. How they are resolved might be different of course. > One for the FMA issue which can/should be solved at the tree level (and that > is a regression). > > The other is the CSE, we should be able to uncse (rematization) during > register allocation to reduce register pressure; I think this has been filed > already. A more general rematerialization pass would certainly be very useful for lots of cases. However it wouldn't improve any of my examples as they are not about spilling (when you run out of registers it is more efficient to do more work to recompute values rather than spill and reload them).
[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399 --- Comment #12 from Ludovic Courtès --- (In reply to Ludovic Courtès from comment #10) > In fact, the revert only needs to be done on the initial > pseudo-cross-compiler that is used to build the native compiler (I'm > attaching a PDF of the dependency graph, where the initial > pseudo-cross-compiler as described at > http://linuxfromscratch.org/lfs/view/stable/chapter05/gcc-pass1.html is > marked as "gcc-cross-boot0", and the final native compiler is simply "gcc"). > > To summarize, if we build 4.9.4 with a cross-4.9.3, that's fine; if we build > 4.9.4 with a cross-4.9.4, we get the bootstrap comparison failure. The faulty commit is r231177 (commit f6ab85b7049a03962ea98924d00802da357a1ad3 in the Git mirror). If we take 4.9.4 and revert r231177 in the "gcc-cross-boot0" compiler, then the final gcc builds fine (no bootstrap comparison failure). Note that the revert needs not be applied to the final gcc, only to gcc-cross-boot0. (For reference, we applied the revert here: http://git.savannah.gnu.org/cgit/guix.git/commit/?id=e7e43727ce7b3426a31b2f50b035a5b0aba61d52 .) Any idea what's going on here?
[Bug c++/77496] ICE in instantiate_type, at cp/class.c:8270
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496 --- Comment #5 from Bernd Edlinger --- Author: edlinger Date: Mon Sep 12 20:18:16 2016 New Revision: 240098 URL: https://gcc.gnu.org/viewcvs?rev=240098&root=gcc&view=rev Log: gcc/c-family: 2016-09-12 Bernd Edlinger PR c++/77496 * c-common.c (warn_for_omitted_condop): Also warn for boolean data. gcc/c: 2016-09-12 Bernd Edlinger PR c++/77496 * c-parser.c (c_parser_conditional_expression): Pass the rightmost COMPOUND_EXPR to warn_for_omitted_condop. gcc/cp: 2016-09-12 Bernd Edlinger PR c++/77496 * call.c (build_conditional_expr_1): Call warn_for_omitted_condop. * class.c (instantiate_type): Look through the SAVE_EXPR. gcc/testsuite: 2016-09-12 Bernd Edlinger PR c++/77496 * c-c++-common/warn-ommitted-condop.c: Add more test cases. * g++.dg/ext/pr77496.C: New test. * g++.dg/warn/pr77496.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/pr77496.C trunk/gcc/testsuite/g++.dg/warn/pr77496.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/warn-ommitted-condop.c
[Bug c++/77496] ICE in instantiate_type, at cp/class.c:8270
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496 Bernd Edlinger changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Bernd Edlinger --- fixed on trunk.
[Bug target/77570] New: [msp430-elf] Wrong assembly in delay_cycles_32x insn declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77570 Bug ID: 77570 Summary: [msp430-elf] Wrong assembly in delay_cycles_32x insn declaration Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: oarias at knights dot ucf.edu Target Milestone: --- Created attachment 39607 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39607&action=edit Patch which fixes the assembly issued by the delay_cycles_32x insn. Greetings, We ran into a bug this weekend and traced it back to the following. The delay loop insn for loops with 32bit constants currently does the following: (define_insn "delay_cycles_32x" [(unspec_volatile [(match_operand 0 "immediate_operand" "i") (match_operand 1 "immediate_operand" "i") ] UNS_DELAY_32X)] "" "PUSHM.A #2,r13 MOV.W %A0, r13 MOV.W %B0, r14 1: SUB.W #1, r13 SUBC.W #0, r14 JNE 1b TST.W r13 JNE 1b POPM.A #2,r13" ) The assembly issued by this insn is not correct. According to the CPUX description of the pushm and popm instructions, the list of registers saved is from n-1 to the listed register in the instruction. As such, pushm.a #2, r13 ; saves r12 and r13 in the stack, and popm.a #2, r13 ; restores r12 and r13 from the stack However, in this loop, the compiler uses r13 and r14 as temporaries. However, it does not save r14 into the stack, corrupting its value. The attached patch fixes the insn. I have not checked whether a similar situation happens somewhere else in the msp430-elf backend. Thank you. Cheers, Orlando.
[Bug libgcc/77571] New: __clear_cache is broken on platforms that report different cache line sizes across CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77571 Bug ID: 77571 Summary: __clear_cache is broken on platforms that report different cache line sizes across CPUs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: beurba at microsoft dot com Target Milestone: --- This patch introduces a problem: https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00076.html and should be at least reverted. See https://github.com/mono/mono/pull/3549 and http://www.mono-project.com/news/2016/09/12/arm64-icache/ There is also some work going on to fix this on kernel level: https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00076.html
[Bug target/77571] __clear_cache is broken on platforms that report different cache line sizes across CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77571 Andrew Pinski changed: What|Removed |Added Target|arm64 |aarch64*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-12 CC||pinskia at gcc dot gnu.org Component|libgcc |target Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/77571] __clear_cache is broken on arm64 for big.little where the cache line sizes are different between cores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77571 --- Comment #2 from Andrew Pinski --- really there needs to be no caching at all because the code could migrate between the cores.
[Bug target/77571] __clear_cache is broken on arm64 for big.little where the cache line sizes are different between cores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77571 --- Comment #3 from Andrew Pinski --- That is even reverting the patch can still cause issues. Really this code should just hard code 4 as the smallest size. Or change the loop to get the sizes through the whole loop.
[Bug target/77570] [msp430-elf] Wrong assembly in delay_cycles_32x insn declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77570 --- Comment #1 from dj at gcc dot gnu.org --- Author: dj Date: Mon Sep 12 21:27:48 2016 New Revision: 240101 URL: https://gcc.gnu.org/viewcvs?rev=240101&root=gcc&view=rev Log: 2016-09-12 Orlando Arias PR target/77570 * config/msp430/msp430.md (delay_cycles_32x): Fix pushm/popm. Modified: trunk/gcc/ChangeLog trunk/gcc/config/msp430/msp430.md
[Bug target/77570] [msp430-elf] Wrong assembly in delay_cycles_32x insn declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77570 DJ Delorie changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dj at redhat dot com Resolution|--- |FIXED --- Comment #2 from DJ Delorie --- Patch applied. Thanks!
[Bug c++/77572] New: wrong value for extended ASCII characters in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77572 Bug ID: 77572 Summary: wrong value for extended ASCII characters in diagnostics Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Similar to bug 77520, when quoting string literals in diagnostics using the %qE directive, GCC sign-extends characters with values in excess of CHAR_MAX (when char is signed), resulting in nonsensical escape sequences such as the program below. In addition to correcting the %qc and %qs directives to avoid sign-extending characters, the fix for bug 77520 also changed the base of printed characters from octal to hexadecimal. For consistency and better readability, a fix for this patch should do the same (alternatively, if octal is preferred, the %qc and %qs directives should be changed to octal). $ cat z.C && /build/gcc-trunk-git/gcc/xgcc -B /build/gcc-trunk-git/gcc/ -S -Wall z.C constexpr int i = "\x0_\x01_\x7f_\x80_\xff"; z.C:1:19: error: invalid conversion from ‘const char*’ to ‘int’ [-fpermissive] constexpr int i = "\x0_\x01_\x7f_\x80_\xff"; ^ z.C:1:19: error: ‘(int)((const char*)"\000_\001_\177_\3777600_\377"’ is not a constant expression
[Bug c++/77573] New: bogus wide string literals in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77573 Bug ID: 77573 Summary: bogus wide string literals in diagnostics Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- While experimenting with the test case for bug 77572 I noticed that when quoting wide string literals in diagnostics G++ prints what looks like completely bogus sequences: $ cat z.C && /build/gcc-trunk-git/gcc/xgcc -B /build/gcc-trunk-git/gcc/ -Wall z.C && ./a.out constexpr wchar_t s = L"\x12345678"; z.C:1:23: error: invalid conversion from ‘const wchar_t*’ to ‘wchar_t’ [-fpermissive] constexpr wchar_t s = L"\x12345678"; ^ z.C:1:23: error: ‘(wchar_t)((const wchar_t*)"xV4\022\000\000\000")’ is not a constant expression
[Bug middle-end/77574] New: Wrong if condition in predict.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77574 Bug ID: 77574 Summary: Wrong if condition in predict.c Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Target Milestone: --- Hi, an experimental version of my -Wint-in-bool-context patch found this apparently wrong code in predict.c ../../gcc-trunk/gcc/predict.c: In function 'void force_edge_cold(edge, bool)': ../../gcc-trunk/gcc/predict.c:3726:36: error: ?: using integer constants in boolean context [-Werror=int-in-bool-context] if (e->probability <= impossible ? PROB_VERY_UNLIKELY : 0 ~^~~~ && (!impossible || !e->count)) ~ I think it is meant this way: if (e->probability <= (impossible ? PROB_VERY_UNLIKELY : 0) && (!impossible || !e->count))
[Bug c++/77575] New: Bogus error when alias template yielding a reference type used as template template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77575
Bug ID: 77575
Summary: Bogus error when alias template yielding a reference
type used as template template argument
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Reduced from http://stackoverflow.com/q/39460120/2756719:
template class> struct meow {};
template using kitty = T&;
meow u;
results in the following bogus error:
prog.cc: In instantiation of 'struct meow':
prog.cc:4:13: required from here
prog.cc:1:46: error: type/value mismatch at argument 1 in template parameter
list for 'template class > struct meow'
template class> struct meow {};
^
prog.cc:1:46: note: expected a class template, got 'kitty'
prog.cc:1:46: error: type/value mismatch at argument 1 in template parameter
list for 'meow< >::meow'
prog.cc:1:46: note: expected a class template, got 'kitty'
It compiles fine if 'kitty' is instead defined as T or T*.
[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77420 kargl at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from kargl at gcc dot gnu.org --- Seems that the patch to fix this pr has caused a regression. See https://gcc.gnu.org/ml/fortran/2016-09/msg00039.html
[Bug lto/77576] New: gcc-ar doesn't work if all options are read from file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576
Bug ID: 77576
Summary: gcc-ar doesn't work if all options are read from file
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: likan_999.student at sina dot com
Target Milestone: ---
For some build tools, they use @file intensively, i.e. putting command line
arguments into a file, and run
gcc-ar @some-file
This will break, basically due to these code snippet in gcc/gcc-ar.c:
if (is_ar && av[1] && av[1][0] != '-')
av[1] = concat ("-", av[1], NULL);
This basically says, if the first argument doesn't start with '-', prepend one
to it. So the command passes to underlying at is
ar --plugin=... -@some-file
and obviously ar doesn't recognize -@ as an option.
A quick and dirty fix would be changing the condition to
if (is_ar && av[1] && av[1][0] != '-' && av[1][0] != '@')
however, a better change would inspect the file content and prepend '-' to the
first argument. But that involves some bigger change.
Can anyone fix this?
Thanks.
[Bug lto/77576] gcc-ar doesn't work if all options are read from file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576 Andrew Pinski changed: What|Removed |Added Severity|major |normal --- Comment #1 from Andrew Pinski --- Yes this is a bug. We should be handling response files correctly here. But really there is less of a need for gcc-* now that you can install the lto plugin in a place where binutils will automatically pick it up.
[Bug c/77577] New: missing warnings about too few array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77577
Bug ID: 77577
Summary: missing warnings about too few array elements
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
With a declaration of 'f' as in the following code the function implementation
can assume that at least the given number of elements are available in the
array. According to ISO C:
If the keyword static also appears within the [ and ] of the array type
derivation, then for each call to the function, the value of the corresponding
actual argument shall provide access to the first element of an array with at
least as many elements as specified by the size expression.
Given the following code gcc (in trunk and previous versions) does not emit a
warning. It should be possible to emit one. Especially with recent changes
which make __builtin_object_size usable even without optimization.
int f(int ss[static 5]);
int g() {
int ar[2];
return f(ar);
}
[Bug c/50584] No warning for passing small array to C99 static array declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584 Markus Trippelsdorf changed: What|Removed |Added CC||drepper.fsp+rhbz at gmail dot com --- Comment #13 from Markus Trippelsdorf --- *** Bug 77577 has been marked as a duplicate of this bug. ***
[Bug c/77577] missing warnings about too few array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77577 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf --- dup. *** This bug has been marked as a duplicate of bug 50584 ***
